another post of limited interest to non-techies. although, it would be good if you could comment on whether or not you understand the concepts that directly effect you as a website user who doesn’t think about security.
i’ve been thinking about this for a while, but never really got around to writing anything about it. today i was reading this article about how the “change your password once a month” policy is bad and figured i’d throw some stuff down. it will most likely be ignored unless it happens to come up in search engines.
the first thing to remember in all of this is that the server is attempting to authenticate that the user is the user who created the account, not that they are a specific person in the real world.
i have 2 suggestions for ways to improve web application security that use existing technology. the first could be fairly easily implemented by browsers and requires no changes on the server side. the second requires server side changes and browser changes, but are fairly simple.
most (all?) browsers already support the ability to store passwords for people. this is a good thing. the 2 current downsides to the implementations are the fact that by default (except for i believe opera) they are not protected by a master password. the other problem is the inclusion, on requirement from the financial industry, to have a way to block passwords from being remembered. this is nonsense. what this has caused me to do is to store my passwords in clear text file on my computer. yeah security! i do know that there’s a firefox extension that allows this to be disabled per site, but i never get around to bothering to find it when i re-install.
my first suggestion involves fixing those 2 problems. easy enough for the browser developers. the master password functionaility already exists (take this opportunity to turn it on in your browser) and the other just requires turning off a stupid anti-feature. the main addition is implementing a password generator within the browser. there’s a program on linux/unix (surely other platforms) named apg (automated password generator) that does this for pronounceable passwords. it uses a n.i.s.t. algorithm described in fips-181. of course, sense you aren’t going to be remembering these passwords, they can just be completely random printable characters. this should then be integrated into the password input field in some way. for example, a small button next to the field with a tooltip of “generate password” (could be done by sites now using javascript and be browser independent. better to have it available on any site though) or maybe a context menu entry. possibly only showing this when a stored password is not available. now, when the user creates a new account at a website, they simply generate a password that is stored and they don’t even have to know it. the password is random so there’s no guessing the password. your only real weak link is if the website uses poor security in storing the password and then gets cracked. the browser master password is less important since it requires physical access to be worth anything. it should still be a good password, but it’s the only one you have to remember.
simple enough, right? it could probably be implemented as a firefox extension if one were so inclined.
an addition to this would be a move to using basic or digest authentication at the http level with https. this would remove the annoyance of using cookies for session authentication. this allows for cookies to be disabled and still use websites. additionally, the user would get a consistent authentication dialog unique from any possible site created dialogs to prevent spoofing. it’s also a real annoyance and usability issue to have to try and vulcan mind meld with the site creator to figure out how to logon and off on some sites. the browsers should also implement (i believe opera does) a way to clear basic and digest authentication information from the browser.
the second thing is a bit more complicated, but only a bit. it’s generally similar to how ssh public key authentication works. the first step is implementing support for self-signed client side certificates on the servers. this requires ssl for all authenticated connections. any server load complaints for this are nonsense. the next step for the server is to implement a way to store the public key for a certificate associated with a user (maybe even more than one). the easiest way to do this would be when the user first creates an account. the new account link would go to an https site that detects the client certificate supplied by the browser. the certificate information could be displayed to the user. the user would then continue with account creation including a userid for the site, etc. the server now knows that userid foo goes with the supplied client certificate. using a certificate signed by a c.a. is irrelevant, though not forbidden. if one feels the need, they could easily use a c.a. signed certificate for every site. however, the goal would be to use a different client certificate at every site. how a user can change their client certificate is left as an exercise to the reader. i always wanted to say that.
there are some browser modifications that could make this an easier process. currently, the browsers have everything required to use client certficates. the main enhancement involves adding a dialog when a server requires a client certificate. currently, this will show a dialog with the already installed client certificates. this should now include an option to generate a new self-signed certificate and associate it with the given website. easy enough. this allows the user to either use the same certificate for every site or generate a separate (preferred) for every site. i would think this could be explained to the user in a couple of paragraphs or less, but never under estimate stupidity.
the key principle to remember is that you’re only authenticating that it’s the person who owns the account. not that they’re a specific real world person. this system would also prevent social engineering (probably the biggest problem with security) since the user has no idea what their password even is so they can’t possibly give it away.
it would also be helpful if browser authors would make it easy to migrate authentication information between machines so that i can easily have my auth info on both a desktop and laptop. i don’t know if firefox is better now, but previously it was a pain in the ass close to impossible.
feel free to post complaints in the comments. my hide is thick and very durable. i will, of course, then be forced to point out why you are wrong. the first complaint would probably be, “but what about when i’m using a computer at an internet cafe”. the answer is simply don’t. if you are, you aren’t concerned about security. they are completely insecure. a key logger could easily be installed. if it’s really a problem, write down your password and put the piece of paper in your wallet. if your wallet is stolen, the least of your worries is losing your password(s).
After a quick read I was reminded of something I read that might be of interest, OpenID. OpendID Enabled offers additional information and something named Yadis (sound close to the new Toyota car Yaris).Might this fit your requirements? In addition, I ran across his reference to use with WordPress.
you sent me this before, but i never got around to reading it.
it’s better than something like passport that’s centrally controlled. however, it seems to me that it’s complicated and solves a problem that i don’t have, using the same id across multiple sites. of course, it solves their target problem of blog comments.
it also depends on people having an http url. for the vast majority of the population this will be a problem until yahoo or amazon or google adopted this spec. you also have to be currently logged into your home site for it to work. similar to the client certificates there’s probably a large overhead for getting random users to move from userid and passwords which they understand.
Perhaps the statement “the first thing to remember in all of this is that the server is attempting to authenticate that the user is the user who created the account, not that they are a specific person in the real world.” needs to be revised. It would seem to me that what we are really doing with login/password is simply agreeing that authorization for access has been granted to the holder of the login/password. The login/password can be client created, administrator assign, etc. The login/password can be “provided” to one or more clients to access a server. Actually, in real-life, many provide the same login/password for many servers. I guess the latter falls into the exposure followed with inference as defined in the related article.
i think we’re saying the same thing. i had just wanted to point out that for sites like yahoo or google or something it’s not important to know that someone is actually “joe smith”. the same user id and password should not be used for multiple people ever. even for, especially, administrators.
the same user id (especially e-mail addresses) and password should not be used for multiple sites. for instance, pay pal. if you have their e-mail address you know their user id. now you can send them an e-mail for an unrelated site (or a porn offer i believe was in the article) and, for most people, there’s a good chance that they will use the same password. you now have access to their pay pal account.
This is a brilliant post and absolutely on the mark. Just got around to reading it. One little issue is that some sites have password rules that a password generator may need to know to generate a valid password. Of course, I expect that any ‘good’ password generator would pass 99.9% of the time. I especially like the idea of a less basic (more secure than clear text) basic auth.
The issue of gaining access from a different computer is of concern to me. I know you’re going to say don’t do it. The reality is that access is needed in arbitrary situations. You need to work on some way for the user to gain access from scratch from a different computer without having to manually migrate one’s password bag from some browser (i.e., how can I prove to you that I should have access to this account?). Here’s the scenario. I go to London to watch football for 4 months. I don’t take a computer – or I do, but it crashes. I go buy one at the store and I need to get up and running from there. How do I do that? Oh, BTW if I had the passwords on a memory stick – I lost it in a pub while scrambling to get away from some rabid baseball fan.
For me, I think I’d be happy to have my credentials stored on a server somewhere (perhaps that I own or control) that has normal uid/password access with a single good password. If you had that (as the credentials bag could just be a relatively opaque bag of bits) the browsers would just need to give you some way of setting the site for storing your credentials.
And here’s another thing. We’ve got to get this spam situation under control. So, I’d like you to come up with a way to do that. Here’s a partial thought for you to consider. Remember finger? This was a pretty good idea. I’m thinking of something similar execpt that it’s a separate channel for your e-mail for people to 1) check to see if they can send you e-mail, 2) request to be added as an authorized source for e-mail to you. Then you’d just integrate into the e-mail client a way to review all the requests for addition to your e-mail authorization list – which by definition must be separate from just sending you an e-mail. There could only be one distinct source in your request list (a repeated send would just update the request) once denied the user would not be able to re-request for some period (or optionally forever).
The new channel could be integrated into clients such that when an interactive piece of mail is sent it could allow for 1) checking ability to send to you, and 2) prompting for a message to send to your authorization request channel, and 3) allow message queueing until the check succeeds or officially gets back ‘blocked’ vs ‘not authorized’ (which I guess could be in the smtp server).
The core of the idea is to only allow e-mail from trusted people (which I realize could be done now – however, it prevents getting mail from someone to which you may have given your business card in the past), but have a standardized way that people can request to be added (e.g., Hey dude, it’s me – i just got this new account x@y – add me to the list or I’ll disrespect your favorite football team, etc.).
i’ll post something on spam/e-mail eventually. generally, i would say that a whitelist is a requirement. basically that’s what you were suggesting.
re: the sandy’s post on the article
password requirements are a non-issue. the generated passwords would easily pass anything possibly required. if not, you can always enter your own.
the dooms day scenario you described is just a fact of life. why were you carrying your backup around with you? the re-install of the o.s. (not uncommon for windows users) is a small issue. assuming you don’t have a backup, you’re back to square one using whatever mechanisms the sites require or wait until you can get to your real backup when you get back home. posting your bag-o-credentials on the internet is a possibility, but you would ultimately want that password to be really good. possibly written down in your wallet. i personally don’t feel the dooms day scenario happens frequently enough that it’s worth the effort. easiests answer might be just having printed copies of your most important passwords in your wallet. my biggest issue would be losing my ssh private key.
the preference would be that this bag-o-credentials was integrated at the o.s. level instead of a specific application. or really a separate application like ssh-agent. mac o.s. x has such a system. there’s also roaming profiles for mozilla (i guess it’s in firefox?), but i don’t know if that stores passwords. also, all the different kinds of credentials (ssh key, pgp key, passwords, x.509 certs) should be stored in one common bag-o-credentials.
Re: password generator issues. This is actually an issue (of course you can just set one yourself), but the fact is you have both sites that, for example, require at least one special character and/or don’t allow special characters. That’s the sort of intractable situation I was thinking of. I really like the idea of being able to set a site for storage of my bag-o-credentials (e.g., rsync to wherever with credentials from the bag). Just keep them copied there. When I set it in a new browser, suck-em down. Just keep the access to the bag master password protected on each browser. I really prefer the idea that no one knows their actual site passwords and further that they require a client certificate that’s unique and auto generated.
re: password requirements
i hadn’t really consider the situation where sites can’t accept certain characters. the easiest would be to just extends the input tag to take an attribute that would allow a regex to set what characters are acceptable. this would also be general useful. i think the w.h.a.t. people added something like this. could also be done relatively easily with javascript, but not requiring javascript is desirable. the requirements would also have to be available to the generator.
I believe I have seen proposed
solutions on how to assist users with multiple sets of
login/passwords for accessing different systems. If I recall
correctly, their server tracks these, much like you were proposing
the web browser do, and logins to each target system on your behalf.
I tried to find references. Here is one
that is not exactly like I am talking about, but seems similar to
what you are proposing.
i’ve seen programs like this before. the problem is integration with the browsers and other applications. they also don’t handle generating passwords which is really the bigger issue. most browsers already can store the passwords.