Re: Re (2): Multiplicity of accounts.
Not top posting, just prefacing my comments:
Are we trying to educate the list in cracking techniques or in ways to
manage and mitigate the vulnerabilities?
On Fri, Oct 4, 2013 at 10:36 PM, Jerry Stuckle <jstuckle@attglobal.net> wrote:
>
> 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?
Exposure here would only motivate the banks if they were reading this
mailing list.
Exposure here would only warn their customers if their customers, or
even their customers' friends, were reading this mailing list.
I don't think it would be responsible to name names here, do you?
However, for users of this list, trying to manage the vulnerabilities
they expose themselves to, the odds that your bank is using known
vulnerable techniques are high enough that you need to take some
effort to limit your own exposure.
>>> 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.
Do you know all the places the flash code you've written can break?
And Flash isn't the only place code fed to the browser can break the
browser, of course. Javascript, even Google's implementation, still
has vulnerabilities. Every plugin could break the browser, and
specific discussion of where browsers could break should be
unnecessary here. Unless you want me to teach the list cracking
techniques, which I'm inclined to try to avoid.
Calling the stuff HTML 5 did not fix all those, it just laid out a
framework within which a properly written HTML 5 compliant web page
can avoid the worst problems.
> Just because it is flash does not in itself say whether the code is safe or
> not.
I'll go with that the day the last vulnerability gets published. :-/
> And once again, even if it flash from an advertiser on another domain, it
> will not be able to harvest your userid/password.
In the ideal world. All it takes is a successful code injection to
break that, even when the domains are done right.
And the domains are too often done wrong. Describing how is not
appropriate here.
>>>> 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.
So, you want to explain Google's universal login to us?
Sure, it requires a certain level of incompetence to expose cookies,
but the incompetence is still (after about fifteen years) there,
because people want to share information, and they don't want to do it
the right way.
Which actually brings us back to the topic of this thread, the reason
for multiple user ids and group ids. You manage data by limiting its
use, and that means limiting the user processes that can access the
data. That means crafting groups or resorting to ACL-like stuff, and
ACL and that kind of thing are like leaving your store's cashbox
locked in the middle of the road when you go home for the night.
Whether Google went too far in joining/providing universal login, or
whether they are trying to help mitigate the overall risks by
providing a best way to do a wrong thing that far too many people want
to do, I'm not going there. That is, I have gone through the arguments
for myself and I'm not sure which way I'd go if I were in charge of
such things at Google.
And again, I find myself hamstrung in this conversation by a lack of
desire to educate more random people in ways to find the exposures.
Finding the exposures is not what I want to encourage, although, if
you have to convince yourself, they are easy enough to find. What I
want to encourage is responsible use.
>>>> 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.
Easier said than done. None of the banks I have access to are going to
provide better alternatives, among other problems.
>>>>> 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.
And you are wrong about that. Sorry to be so blunt, but that's the way it is.
I'll go through this again. I won't make reference to the problem of
using an admin user to surf the web, I'll just focus on the problem of
exposing bank passwords, account numbers, etc.
I surf out to twitter or Google+ to check what some famous person has
said about something. Maybe a comment from Thorvalds has gone viral
again, and I want to find out what he really said. In the conversation
that follows, I find a link that happens to redirect to
dubious-ads.com, but I don't notice that because the url in the link
was to one of those aliasing services, or even just a less dubious url
owned by the same company or a sister company.
dubious-ads.com, in spite of their name, is usually actually mostly
just a nuisance, but today they've been hit by some 0day and there is
a drive-by hiding in their ads. That drive-by drops a bit of malware
in my browser's cache. (Not saying where or how because, as I said,
I'm not trying to teach how to write the drive-by.)
I intend to close the browser and restart to clear the cache, but I
happen to have another instance of the browser running, minimized or
on another desktop. So the cache is not cleared.
Then I visit Amazon because an ad on dubious-ads.com made me think of
something I wanted to buy. But I don't log in there, just look at
prices. Again, I close the browser, thinking I've cleared the cache,
but I still have the other instance out there running.
Now I go to the bank to check my balance. And that bit of malware logs
what I type into the webforms and passes that off to the black-hats
somewhere.
Now you can argue that web browsers don't allow that, but you can't
prove that browser developers have squelched the last bug, even if I
happen to using the most up-to-the-last-minute version of the browser.
Now that's stuff that happens every day even in the most ideal
circumstances. In the real world, browser vulnerabilities allow
writing outside the cache area, and you're not likely to notice that
you've got something strange automatically starting up, and that it's
not something you intended to automatically start up. So even logging
out and back in to the same user puts you at greater risk than logging
out and then logging in as a different user.
And that's why it's just better to log completely out, and log in to
an account with a different userid, password, and home directory to
access the bank.
It's not perfect, because going from writing outside the cache to
writing outside the user's home directory is a matter of privilege
escalation, and escalations often exist, but the escalations are extra
steps, are not as well known, and are often mitigated or protected
against by other methods.
Writing outside the cache is supposed to be blocked by the browser, or
by its implementation of javascript or the plugin architecture, etc.
Writing in areas where the user has no permissions is supposed to be
blocked by the system, itself. Not perfect, but a significantly higher
wall.
> If you use the same password on multiple sites,
> your additional userid won't help you.
No argument about that. Did you see me anywhere suggest that multiple
login ids on your own machine would make it safe to use the same
password at your bank that you use at slashdot or facebook? If I
implied that, tell me where and I'll post a follow-up to try to limit
the damage.
> 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.
And I have definitely used time here that I needed to be using on
other things. I'd appreciate it, Jerry, if you would think through any
further quibbles before posting them. I have a ton of homework for the
class I'm taking, and a bit of prep for the classes I'm teaching next
week.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
Reply to: