Re: Re (2): Multiplicity of accounts.
On 10/4/2013 5:10 AM, Joel Rees wrote:
> Should I add to the confusion?
>
> On Thu, Oct 3, 2013 at 10:27 PM, Jerry Stuckle
<jstuckle@attglobal.net> wrote:
>> On 10/3/2013 8:45 AM, Joel Rees wrote:
>>>
>>> On Thu, Oct 3, 2013 at 1:53 AM, Jerry Stuckle <jstuckle@attglobal.net>
>>> wrote:
>>>>
>>>> On 10/2/2013 12:24 PM, peasthope@shaw.ca wrote:
>>>>>
>>>>>
>>>>> From: Joel Rees <joel.rees@gmail.com>
>>>>> Date: Wed, 2 Oct 2013 15:30:26 +0900
>>>>>>
>>>>>>
>>>>>> [...]
>>>>
>>>>
>>>>>> And accessing your bank logged in as the same user that you use to
>>>>>> surf random sites is one of the primary causes of leaked bank
account
>>>>>> numbers and passwords.
>>>>>
>>>>>
>>>>>
>>>>> The banking information is stored in a cookie. Subsequently a site
>>>>> other
>>>>> than the bank is allowed to read the cookie? A failure of the
browser.
>>>>> Correct? Prior to studying this thoroughly, I might stick to
personal
>>>>> banking.
>>>>>
>>>>
>>>> Not if your browser is working properly. Cookies can only be sent
to the
>>>> domain which originated them (and, depending on the cookie options,
>>>> subdomains of the main domain).
>>>
>>>
>>> subdomains.
>>>
>>> And too many places, bank sites included, outsource parts of their
>>> sites. Particularly ad-related stuff.
>>>
>>
>> It doesn't matter if they outsource parts of their sites. Those
outsourced
>> sites will have different domains, and the cookies cannot be sent to
them.
>
> You must be looking at the page source code of different banks than I am.
>
What banks do you know outsource subdomains to someone else?
>> And no bank would be stupid enough to create a subdomain and hand it
over to
>> some unknown entity. They wouldn't be in business for long if they did.
>
> Banks should be smart enough to not use flash on any part of any page
> where they have people logging in. Maybe there are some that are, but
> there sure are many that aren't.
>
So what? If they wrote the flash code, they know whether it is safe or not.
Just because it is flash does not in itself say whether the code is safe
or not.
And once again, even if it flash from an advertiser on another domain,
it will not be able to harvest your userid/password.
>>> I play it safe and limit logging in to my bank to a user that does
>>> nothing but logging into that bank. Hey, it's my computer, I can add
>>> users all I like.
>>
>> Which doesn't make any difference because that's not where the leaks
occur.
>
> Huh?
>
> I mean a user on my computer. Dedicated to one bank. Reduces the odds
> that a drive-by from, say, a song lyrics site, will still be sitting
> in my browser when I visit the bank. If a drive-by does get root,
> there's no help for that, but at least I can protect myself from the
> drive-bys that only get local access.
>
Which still makes no difference, because the lyrics site will not be
able to read information from your banking site.
>>> And I try to avoid logging in to the bank, but the bank sometimes
>>> requires me to log in to do certain things, now.
>>>
>>
>> I would hope they require logging in to do *anything* with your
accounts.
>
> I was thinking of things that you used to be able to do at the teller
> window in the physical bank, which they now charge service charges
> for, but are free if you do them from an ATM or over the web.
>
> I was assuming that much would be understood, since we are talking
> about protecting passwords and such things. Guess I should have tried
> to make that a little more clear.
>
My bank doesn't charge for doing things at the teller window. Neither
does my wife's. Maybe it's time to change banks.
>>>> But too many people use the same userid/password for multiple
sites, and
>>>> a
>>>> security problem on one site can expose those userids/passwords. This
>>>> makes
>>>> it easy for a hacker to access one's banking account.
>>>>
>>>> I use online banking all the time. But I have a unique
userid/password
>>>> combination on each of my accounts. These are long, non-obvious,
known
>>>> only
>>>> to me and not stored on any computer.
>>>
>>>
>>> That's important, too. Which means that the problem here is getting
>>> used to manage more than a few userids and passwords, and most people
>>> are intimidated by what it takes to get that experience.
>>>
>>
>> It's not all that hard if you come up with a system. For instance,
take a
>> phrase you know very well, i.e "To be, or not to be: that is the
question".
>> Take the first character of each word (numeric homonyms become
numbers), to
>> get 2bon2btitq. If the first word starts with a-m, capitalize the
>> odd-numbered letters; otherwise capitalize the even numbered
letters. So
>> you get 2BoN2BtItQ.
>>
>> (You might not want to use a phrase quite that well known, but it is
only an
>> example).
>>
>> Different phrases for different sites. Even of someone gets one
password,
>> they won't be able to guess passwords on other sites.
>> Archive: [🔎] 524D70C0.7080302@attglobal.net">http://lists.debian.org/[🔎] 524D70C0.7080302@attglobal.net
>
> You have your techniques and I have mine and we can handle more than
> one password, so why shouldn't we be able to handle more than one user
> id?
>
I didn't say you couldn't use another userid. All I said was it adds
nothing to your security. If you use the same password on multiple
sites, your additional userid won't help you. And if you use different
passwords on each site, your additional userid won't matter.
> But this thread was originally talking about why sharing a file on a
> computer between multiple users take so much thought and effort and
> using less familiar tools, like chown and chgrp and groupadd and
> useradd.
>
> --
> Joel Rees
>
> Be careful where you see conspiracy.
> Look first in your own heart.
>
>
Jerry
Reply to: