I’m sorry, but were you actually trying to remember your comical passwords?
troyhunt.com
troyhunt.com
I think passwords are fundamentally broken as a security mechanism, once you take human psychology into consideration. We've spent decades trying to teach people to pick better passwords. That didn't work; people still pick stuff that gets cracked in minutes. And now, as Randall Munroe said, it turns out that the "better" passwords we taught people to use are actually very bad. Great, let's spend the next 3 decades teaching people to use long passphrases, and watch that fail too. Then we can start teaching them to stop sharing and reusing passwords (good luck).
A security token (http://en.wikipedia.org/wiki/Security_token) is a fundamentally better solution to authentication. It's not perfect and it's not a panacea, as the RSA security leak/breach shows. But it's better than a completely broken paradigm. Once these tokens acquire enough compute power to perform challenge-response calculations internally, they will be very safe even at untrusted terminals. They've already become ubiquitous in places that really care about authentication on a large scale (like the military), and they should become ubiquitous everywhere. You can have several of them (one for banking sites, one for social...), to avoid single points of failure. They are reliable, and you know when you've lost one. A leaked password manager password, on the other hand, could have the attacker using your logins for months.
A technical solution is preferable to a solution which involves changing human behavior on a massive scale; that is just not going to happen.
That's only half the story as without the password keychain (in the 1Password example), the master password itself it useless. So now you've got to extract a human memory-bound password AND compromise their machine / device / Dropbox to gain access to the strongly encrypted passwords.
I'm with you in wanting a better alternative to passwords, but for now password managers are the best mousetrap we've got. But it's not as easy to exploit as simply obtaining one password.
EDIT: the other problem (again, psychological) is that you can't require users to have a password manager, even if you think it's a good solution, which I personally don't. Your site is not aware if the password came from a manager or from a keyboard. But once you issue security tokens, they must be used. And often, it's not just the user's problem if someone has their password; once someone is in your network, privilege escalation is usually not far away.
Even for credentials for multiple sites stored on one token (which is less safe), you at least get the ability - even offline - to see what credentials have been provided to whom. It's just a fundamentally better authentication paradigm, although certainly not the solution to all the world's security ills.
I also find the distinction above almost meaningless for webapps: if an attacker has privileged access, you're screwed. Maybe they can't make actions while you're not logged in but they can hijaack the session and control everything you see each time you do login. Using a more trustworthy client is your only realistic option until banks start requiring one-time codes for every transaction.
I'd love to see two factor auth or at least the option of RSA style tokens and we're gradually seeing that in some places but unfortunately we're still stuck with the status quo for the vast majority of sites for the foreseeable future.
And from a technical point of view, all password systems have a weakness of having long-term credentials - a stolen password can be used for months, at any time, until it expires. That part is not fixable.
Carrying a bag of security tokens around with me doesn't sound like a lot of fun - and they're still a single point of failure if you happen to get mugged by an idiot or fall in a puddle.
It's not commonly talked about, but it's possible to have multipassword encryption. I wonder if a password manager out there supports it. (I think GPG can, so if you consider a test file & gpg a password manager... ;) )
One scheme: There'd be the "normal" login, which would be rotated, then another ultra-high-entropy one written down and locked in a safe somewhere. That way when you spaced out your password, it'd not be "whoops, just blew my credentials... all of them".
Yes, if someone who knows you well physically targets you for your password, that person will likely succeed. But he would probably also succeed using this method: http://xkcd.com/538/
Use a password manager.
Export the saved passwords, print on paper, and put in a safe place.
Distribute encrypted versions of the passwords on various systems you use, with one very well known and recoverable password. Or encrypted against multiple passwords.
There's a risk, yes, but it's reasonable fungible.
And yes, actually, GPG is my password manager ;-)
We're in the process of building a new app and I was giving serious thought to the whole password thing, account creation and lowering barriers to entry. What we've come up with is a means of enabling users to go pretty much password free if they so desire.
What we've done is taken the usual email verification/password reset link (something like /keys/65a8c7bc16e759f28d37950664a397d231c552f9) and instead of directing the user to an account setup or password reset page, we use this to authenticate the user and log them into the app. Currently the links expire but I'm toying with extending the length out to a month or more. Users are free to create and use passwords if they prefer.
Internally keys are treated like passwords (we use bcrypt) with the exception that a user can have multiple valid keys and keys expire.
Weaknesses I can see are - someone who has access to email (physical machine) can log in, will it be a pain to launch an app from an email link (for me, yes, but I've seen users do some very rube goldburgesque things to get to websites). Aside from the physical/email access I think it's probably more secure that the usual users' choice of password
A magic URL that will be recorded in plaintext in the logs every HTTP proxy and tcpdump between the user and your webserver, and in the history database of every browser they use?
You'd have to also place a secret code on each page, and reject form data or user requests (e.g. to delete their data, etc.) if the secret code wasn't submitted.
Stop. You are inventing a crazy homebrew authentication system here. One great way to absolutely fuck your site's security is through crazy homebrew authentication/authorization/cryptography.
Do it right, don't do it yourself.
++. When I was walking this road, I answered that question with "I'll use the user-agent instead!" Then I checked that assumption, and the Internet told me that could vary between requests as well. That was the key insight (you can't trust anything) that put me on the road to a much more standard system. (But probably still insecure, since I was younger and working for someone with NIH syndrome.)
You have a browser for a client and HTTP. Please, don't end up on HN as sadly yet another cautionary tale for doing security wrong.
These URLs are exposed in all sorts of places; browser history, proxy servers, web server logs and ISP gateways to name just a few. Never put secrets in URLs and expect it to remain secret.
Here's an objective suggestion - put the proposal over on stackoverflow.com and see what response you get.
The idea was that this may give users a bit more time to think about passwords, and possibly be more secure than the usual passwords. Stating the idea here is giving me some good things to consider
BUT -- because of the site's nature, 1) a hacked/compromised account would have been a minor annoyance at worst, and 2) users weren't expected to log on more than once every month or so.
I think it depends very much on your site's profile.
Thanks for all the comments. Appreciate the "don't deviate from the norm" sentiment, but the norm is horribly broken for most users at the moment, and not deviating from it isn't going to make it better. We learn from our screw-ups, not from dong nothing.
That said, I think I may have a way of doing things that will allow for easier first-time entry to the app (no "create password" wall) when a user clicks on their email invite link - authenticate them by the email key and log them in, but make this key single use and display a notice visible within the app that they need to set a password at some point before they leave (if not, they'll need to hit the "forgot password" link next time)
I'd actually challenge this assertion a bit.
Password management isn't as hard as it should be. I think Bruce Schneier is absolutely right when he encourages users to write down their passwords and store that paper securely -- in a wallet, purse, etc.
The problem, IMO, is that we've told users for years to "never write down passwords!" -- when, in reality, we should've been saying "write down a strong password and keep it safe."
>We learn from our screw-ups, not from dong nothing.
You're braver than I. Screwing up is expected, but security/privacy breaches tend to be among the least tolerated and most remembered screw-ups you can make.
If you do decide to pursue some sort of alternative credential system, it's in your best interest to get a consultation from an experienced security professional, as it could save you black eyes down the road.
(I chose bcrypt because it works in the command line, which I favor, and it runs in Linux, BSD, or Windows. I would have chosen scrypt but there isn't a Windows binary for it yet.)
The first part is interesting, if you had been less verbose an ALL the different accounts you had it would have been a more interesting read.
There are still undeniable issues of using a password manager if you lose the data (or your master password is compromised but lets not get into that).
I've thought a bit about this in the past, mostly relating to setting remote shhd to disable passwords entirely, and only accept PKI logins - what if you need to get in, and don't have your key?
The google 2-factor with optional 'emergency 1-time use codes' that you can print and carry in your wallet is a nice solution to half of the problem (the other half being, if you're not using a computer you control, how do you securely access your password manager?)
I don't really have a solution, other than "remember to take your phone with you", and possibly "ensure that at least your primary email is accessible via 1-time codes or a memorable (and strong) password."
I use the Chrome and Safari 1Password extensions for 1-click logins, and it's a setup I'm extremely happy with. On the few occasions I've needed to access an account without access to my 1Password, I've reset my password via my personal email address and changed the password when I next have access to 1Password. I'm not going to pretend password managers solve all problems, but they certainly help.
And he's right, if that's your handicap, a password manager is probably the right crutch.
Not saying a password manager isn't a very useful, convenient and most definitely secure tool otherwise, but wow. Doesn't he realize you don't need to give every website every little tidbit of information they ask you? Or that if they do require it, you're allowed to lie your tits off? And that you really don't need to re-use the same account over and over again if you buy at the same place?
And finally, that if some business does require all this information about you, as well as requires it to be true and unique, you probably shouldn't just suck it and bend over, unless, possibly it's your bank and you really don't have choice?
This is just bad personal information hygiene, yuck.
So we protect our online interests as best we can because we have accounts on Hacker News / Twitter / Stack Overflow / You Tube etc. and even if not exposing PI via the registration process, we expose it via our activities and we want to retain control over that important aspect of our lives. But really, how much information you divulge about yourself is a parallel discussion; I want to protect ANY accounts I create onlne, regardless of how little information I provide.
Using a local password manager, the file could get corrupted or it's not there when I need in in an emergency. Using a remote one, like LastPass, I risk my passwords getting compromised all at once (though maybe not in LastPass' case due to how their architecture works) or, again, not having access to them when I need them.
I have too many machines I'm using for various kind of work where I need different types of passwords. Too many to sync over my passwords and some not even my own, so I don't even want to sync anything there.
Now I have 4 strong passwords I use. One for banking/financial stuff only, one for work, one for "valuable" private accounts bound to my identity (this account here for example) and one for crappy sites I have to give a password to and I don't care if they lose it.
This way I'm not dependent on that password manager being available at a bad time.
The thought of not being able to log into some server people need me fix just because there's no 3g access in the data center or because an update to the password app on the phone didn't re-import the old data correctly is absolutely daunting to me.
Especially because these kind of failures feel more likely to me than one of my more secure passwords leaking out.
I probably couldn't list them all but the idea is that they each have a common "threat level" and I'm generally able to get the password right for things I use every week first go, then it might take 3 or 4 tries to get it right for services I use less frequently but I rarely have to use the forgotten password link.
Wouldn't a better solution be to use a password manager and always have a current and working copy on you when you go out? I'm pretty sure it's doable and can be automated. Keepass + Dropbox being one possibility but you can make it more robust if you feel the need to.
Reuse of passwords is a much worse alternative than not being able to fix someone's server on the spot.
I export my passwords every once in a while, encrypt them, and put them in my backups. My pw manager can disappear and i wouldn't even care.
If you can't handle backing up an encrypted CSV file, then perhaps the problem lies with you and not with password managers.
Your password manager is only a single point of failure if you only have one copy of the database. You do take backups, right?
Of course then the points of failure become the authentication credentials for that database, in the case of my keepass DB that is the key file and passphrase. The key file I have more than one copy of ferreted away (though obviously not stored anywhere connected to where the keepass DB is stored - keeping a backup of the key file in the same place as the DB would be silly). That leaves the passphrase, which is a set of random words that I do remember.
Using a set of four passwords for all your stuff does not solve one of the main reasons for keeping a password store. The main reason I have different passwords in keepass for every site/account/whatever (aside from one or two things that I might need to gain access to when I don't have keepass available) isn't that I want all my passwords so long and random that I won't remember them: it is that I don't want one hacked site to result in someone getting access to many of my accounts if said hacked account was on a system stupid enough to store passwords in plain text (or some easily compromised format, like SHA1 without a salt or with a salt that the attacker has also gained access to - see http://codahale.com/how-to-safely-store-a-password/ for why). You have no idea how your credentials are stored at the other end, so I err on the side of caution and assume it might not be secure.
I don't mean when someone guesses that the password is "123456" or "passw0rd", or when the password was revealed to a crook by mistake.
I mean situations where say, "gr8shoes" was not secure enough but "h43&22981gTddB%&$!" would have been.
Tools like fail2ban help a little here, but can't do much against a large botnet. Adding artificial delays into the authentication process can slow down a brute-force attempt without inconveniencing real users at all, but that botnet has a lot of time on its hands. It might not happen often, but attempts are made often enough (i.e. more than never) for keeping strong passwords to be worthwhile.
I have a feeling the debate is a bit colored by leftover paranoia from the times when several users shared one computer and the password database was easy to get hold of.
Unless the attacker somehow manages to grab your password database (and not your content, which would be an interesting setup in itself) he won't be able to brute force you. He will only be able to lucky-guess you. And you don't need 24 random characters to block a lucky guess scheme. :)
For example, if it's my google account, the sites name is 'google'. I take the first two characters 'g' and 'o' and think of the first animals that come to mind, (for me it's giraffe and ostrich) then replace all obviously changeable vowels with numbers (so they become g1r4ff3 and 0str1ch). I then concatenate them with a % symbol, prefix with a _ and suffix with a #, giving me a password of:
_g1r4ff3%0str1ch#
Which I think is a fairly strong password. It also means I have a unique password for every site I jave an account with. Of course if you figure out my function then you know all my passwords, which is the reason I change it every year or so.
The only downside is that they don't have a version for Linux. Oh well.
Dropbox + Keepass portable works well for me. I use the password plus a key file which is never in dropbox also, just in case dropbox gets compromised.
http://www.schneier.com/blog/archives/2005/06/write_down_you...
> Microsoft's Jesper Johansson urged people to write down their passwords.
> This is good advice, and I've been saying it for years.
Keepass has an android version also. I have my passwords everywhere I go.
I hope this is useful for somebody: https://gist.github.com/1013465
I also suggest that if you have multiple accounts on a single site, you run "mypass user@domain.com" instead of just domain. It works fine either way, just be sure you are consistent across all sites, lest you forget your scheme.
I just know that since I started using a password manager, I don't even know most my passwords, they're about twenty characters long, a jumble of characters (letters, numbers, and symbols,) and I'm happy with that.
I don't even think Google's password length is known, is it? I get that this means others don't know how long it could be either, but, that doesn't seem vitally worthwhile. Maybe I'm wrong.
This makes complete sense... they feel that obscurity will aid in defending attacks (esp. if they have some ridiculously small password-space like 6 digits).
Considering it's a small inconvenience when you first create your user password, then from a cost/ben point of view, I can see why they wouldn't advertise this info.
And here is a javascript (client-only) program that I wrote that can generate printable grids:
Admittedly, I don't do Netflix, or iTunes; I use passwords like "I bet shittyforums.example.com uses plaintext" for shitty one-off forums; when I don't care about a site, but want to see its content, I participate in BugMeNot. I actively work to reduce the number of things I'm signed up for.
In properly formed English sentences, each character only has about 1 to 1.5 bits of entropy, and I'm not certain that taking the first letters of words in a sentence would have much higher per-character entropy than that, as the first letters of words are not very randomly distributed.