Re: Re (2): Multiplicity of accounts.
On 10/4/2013 9:25 PM, Joel Rees wrote:
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.
If there were ANY bank which had to read this list to find out they were
exposed, they need a new IT department.
I don't know about where you are - but here in the United States, they
wouldn't get very far. There are many layers of regulations and
protections regarding banking security. And any bank which had such
security exposures as you claim would not be allowed to continue operations.
And no, I am VERY confident ANY bank I have dealt with knows how to
manage vulnerabilities. What makes you think otherwise?
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?
Yes, I do. I wrote it.
The problem is not the flash code breaking; it is hackers who make use
of vulnerabilities in the flash base.
How much flash code have YOU written?
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.
Banks don't use plugins, and javascript is pretty secure. But again,
the problem is not javascript - but it is the hacker's use of javascript
to exploit vulnerabilities. Those vulnerabilities are not cross-browser.
As for plugins - it's the same as any other program. Only install
plugins from sources you trust.
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.
HTML is a scripting language. Nothing more, nothing less. It has
nothing to do with security - as anyone who really understood it can
tell you.
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. :-/
Once again, you don't understand the vulnerabilities.
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 how are you going to get that code injection?
And the domains are too often done wrong. Describing how is not
appropriate here.
No, banking domains are not "done wrong". And you won't describe how
because you don't understand how.
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?
It's simple. The host server calls a Google API with the userid and
password; the API passes back information. The browser is not involved
in the validation.
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.
Nope, cookies cannot be sent cross-domain. Period. End of sentence.
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.
As I said - you can do whatever you want. But you're only fooling
yourself if you think it's going to increase your security.
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.
Again, it has nothing to do with Google login (which, BTW, no bank I
know of uses).
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.
No, I think you're hamstrung by a lack of understanding of basic
programming. You've read a few things on the internet and jumped to
unwarranted conclusions based on inaccurate and/or incomplete information.
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.
It's your choice. And I found it quite easy to change banks, to one
with a better alternative for what I need.
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.
Nope, you're only fooling yourself if you think it adds to your
security. See above.
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.
Wrong answer. Code will not be executed from the cache, especially code
loaded from another site.
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.
Sure I can. Unlike you, I've seen the code (and understand it) - at
least for Firefox and IceWeasel. Haven't looked at Chrome lately, I
admit.
Sure, the code is big and complicated. But you don't have to look at
everything to see the vulnerabilities; for instance screen formatting
(which is a major part of the code) has nothing to do with security.
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.
Not current ones. Security vulnerabilities are very rare - and when
they are found, they are fixed VERY quickly.
And in the very rare chance there is a vulnerability which hasn't been
fixed yet, it is easily handled by the appropriate anti-virus software -
which you should have on your system. If you have it, this can't
happen. If you don't, you won't stop it.
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.
Once again, you're only fooling yourself.
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.
But it is blocked by the system - hardware won't allow you to write from
an application into system space, for instance. And the OS won't let
you write outside of your boundaries in user space.
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.
I didn't say you did. All I said was that is the biggest vulnerability
on the internet.
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.
I have thought through things. It is pretty obvious you are not a
programmer, and do not understand the underlying code. There is nothing
wrong with that - but some of the concepts you've picked up on the
internet are quite incorrect.
Jerry
Reply to: