Pondering best practice here. We have some of this in place on some systems, but I wonder what people think of this. We may try to work towards this for all systems in due course.
Basically, when someone new comes along and "signs up" for something we create an account ID of some sort, and a password. Traditionally the normal practice was to email the password.
There is a simple alternative which is to allow people to pick a password at signup, but, whilst this can be "secure" via https, it causes problems in that it allows people to pick passwords - and people are basically stupid when it comes to picking passwords. People pick easy ones, and the same one multiple sites. So you end up with stupid and annoying passwords "rules" which piss everyone off.
So, the plan is this...
On creating an account, we run the "reset password" process. The account has no password (i.e. cannot log in) at this point, but we email a link to an https page which is one time use and short lived. If apathy rules, then the link times out and the account will have no valid password, needing a "password reset" requiring the email address and some key data such as postcode.
The link offers a password visible on screen (which we warn about with the link). Now, this is a password we have picked, ideally using a TRNG and along the lines XKCD 936, i.e one that is really easy to remember. We have a button to get a new password if the first is offensive (a tad hard to avoid with random words) or was overlooked, etc. And we have some subtle means to allow manual entry of the password which you have to find by doing some research or asking staff (made hard deliberately). Again, relying on apathy to mean people get good passwords. However, the manual password does allow anything.
All of that is via https to avoid snooping, and we immediately store a hash of the password so we do not have a record of it. Obviously we log that the change took place, and the IP address, and we log if it was the first choice offered, a re-picked one, or a manually set one. If ever there is hacking we can say "you must have set a weak password" if it was manual. I am tempted to log how long it was too but not sure if that is sensible. I may allow posting of an SHA256 hash or some such so we don't, at that point, know the password at all (though we would know when you later log in, if we want, so maybe pointless).
A couple of extra tricks would be for the user to be able to load a public key at signup or any time later, and so for the password reset emails to be PGP encrypted as well.
The process relies on the fact that apathy rules. People will have no password (if they don't care) or will have one we picked sensibly, as a default. No password ever actually sent by plain text.
Have I missed anything obvious here, or is this the way things should be done?
Update: Thanks for all the feedback. We are instigating a system wide password library which provides password generation of defined sizes and entropy for users (XKCD style where possible), password hash generation and password hash checking. The checking can, and does, upgrade the hash checked to a later hash function if an old one is being used on next correct login. This allows existing hashes to be upgraded, and allows any future policy change on chosen salted hashing function to be applied in one place. We are also reviewing how we advise customer of passwords when creating accounts and logins.
Subscribe to:
Post Comments (Atom)
Fencing
Bit of fun... We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as mean...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
Have you considered two-factor authentication? If you use TOTP then there are multiple clients (both open and closed) for a variety of operating systems that would allow you to add a layer of security.
ReplyDelete(I use 2FA for Dropbox, Google, and Facebook, using Google Authenticator as the client on my Android phone.)
We have OTP on FireBricks as it happens, and yes, we could consider this for login to accounts and systems.
DeleteOnly smash there is that you cannot actually call using your phone 2FA a lot of the time.
ReplyDeleteThe factors have to be independent. And, plainly, they are not.
Imagine going to a website that said 'Enter your password, then click this link to get a second factor code for 2FA'
You'd laugh - obviously that's not two factor. So why is it that you think your phone is? It is not a separate channel.
A second channel is a genuine token, isolated from the current events of the world, which can't be told what to say by the very network you are accessing, through the same route.
The third channel is a biometric.
In layman's terms,
Something you know, something you have, something you are.
How is the google authenticator app on my phone not a genuine 2FA implementation?
DeleteIt doesn't access the network in any way, and functions just fine in airplane mode.
It's basically an implementation in general purpose software of the same system used by RSA SecurID tokens, isn't it?
Well, I think the point is that it is "one" thing, not "two" things.
DeleteSorry, my fault for being vague...
DeleteWhat I meant is "When I log into my Amazon Web Services account and I have to provide both my password, and a code generated bv my Google Authenticator app within the last 60 seconds, surely those two things are genuinely independent factors, because the Authenticator code hasn't been produced through any network-based interaction with Amazon; it is simply a clever mathematical proof that I currently possess the same phone handset that I had with me when I set the 2FA up".
Don't hash passwords with SHA256! You should use a function specifically designed for password hashing. Reasonable choices include sha256-crypt (which should not be confused with SHA256 itself), PBKDF2, bcrypt or scrypt.
ReplyDeleteThese constructions offer two basic advantages: they are salted, which mitigates against the use of rainbow tables, and they are iterated so as to make them slower to compute. You can choose an iteration count which balances processing time and resistance to brute force attacks.
bcrypt is getting a bit old and has a password length limitation, so if you use it you might want to run the password through SHA256 first. scrypt is the most cutting-edge of all of these, and is actually built on top of PBKDF2.
You can upgrade your existing hashes by computing a new hash when a user logs in (and you thus have the plain text).
I like the plastic cards you provide with ADSL details printed on them. They're probably not very secure in a corporate environment, but for home ADSL (where you're not letting random strangers in your house) they're quite convenient. However because they're so handy, stuck on the side of the router, I've never bothered to change my password away from the default. How about having a space on them to write on your new password once you've changed it? Maybe have the default on a sticker on the card, which you then peel off and write the new one in the space?
ReplyDeleteThe process you describe above sounds ok. You're effectively forcing people to set a decent password within a short time-frame. The workflow will be fairly familiar to the customer: sign up, get an email, click the link, get a password. Sending a short-lived password by email would accomplish the same, but sending a URL is better as it makes it clearer that you don't yet have a proper password.
I like that you use XKCD 936 passwords, it's quirky and a good way to create a strong password. However the fact that they're memorable is fairly irrelevant. Most people aren't logging in to their ISP control panel every day, so still won't memorise the password, and will probably write it down. Again that's not really a problem for home users, and corporate users should have a good password database system in place already. XKCD 936 passwords have the advantage that they're a lot easier to type than a random string. Strong random-string passwords have the advantage that they're not at all memorable, so are harder to capture by shoulder-surfing etc.
I'm not sure about hiding the user-choice reset. If you're allowing someone to set a dumb password, but recording that fact, then all you're getting is the ability to say "I told you so", rather than protecting your system against attack. Why not make the user-choice reset equally prominent but enforce high complexity? You could use meaningful rules like "more than 12 characters, at least X bits of entropy", rather than arbitrary like "at least one letter, two digits, a mirror image of a hiragana and a unicode poo"? That way lazy people can use the XKCD password, and people like me who use a secure password generator and database as a matter of course can use a unique mahoosive random password as usual.
All of the above describes good ways to set a good password. You could instead use other security methods:
User certificates are good, but not commonly used, so would be too much of a learning curve.
2FA is good, but tend to result in asking the user to install a new app, or carry a new gizmo, or something else onerous. I already have two OTP apps on my phone and that's quite irritating enough already.
Having said that, what about 2FA with an app, plus a set of one-time use codes printed and posted to the customer? Home users who only occasionally log in would be able to use the one-time codes. Busier users who would run out of codes could instead use the app. That would be a good way to demonstrate one-time pads to the government :).
Or give up on the idea of doing it yourself and use OAUTH with Google accounts, Facebook accounts etc. The password issue then becomes somebody else's problem.
And remember that once you have a secure login system the out of band password reset becomes the weakness. Adding 2FA, OAUTH, etc is irrelevant if someone can ring up and say "I'm Charlie Example and I've lost my security token, password, Google account, email address and house, can you reset everything for me please?".
Some good points, thanks.
DeleteThe XKCD style passwords aren't very good passwords unless the attacker is doing the simplest brute-force-every-character attack. Dictionary words, even a few of them in combination, aren't difficult to crack with modern means. See https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html
DeleteGood grief, read the XKCD. The level of entropy on these passwords even if the hacker knows the actual word lists used, is still high and perfectly adequate. In practice they don't know the word list or method anyway, so even more secure.
Deleterm42: that post shows that lots of things are a bad idea, but not that 4 truly randomly picked words from a large dictionary are bad (despite the off-the-cuff claim of one of the password crackers).
DeleteIndeed, this article is linked at the bottom of Schneier's post: https://subrabbit.wordpress.com/2011/08/26/how-much-entropy-in-that-password/
I don't like the cards stuck to the router. They're hard to get at where most people shove their routers, and it makes the data too easy for visitors to steal. Also pulling off the clear plastic sleeve that holds the card (the sleeves look untidy to me) pulls text off the router's own label, including the serial number in one case for me. I curse every time I get a new one of these (replacement router, bridge modem etc).
ReplyDelete