Passwords Evolved: Authentication Guidance for the Modern Era
troyhunt.com
troyhunt.com
I loathe when sites require you to set them up as it requires manually generating a series of N-length random strings (ex: eZDWzazuMw0ZzD4nKhxXXVN3) and saving the pair (question plus random text) as metadata associated with the account. Not exactly pulling teeth but it's pretty annoying to manually do that for 3-5 entries.
Even worse offenders are the sites that don't even let you enter a value in a text box but instead require you to pick from a drop down with a handful, say 10-15, of entries (cough United Airlines cough).
And the very worst offenders are the ones that, after successfully authenticating with your password, ask you for the answers to the secret questions every single time you log in (cough again United Airlines cough).
- What is your mother's maiden name?
- What was the last school you attended?
- What color eyes did you have when you were born?
- What was the last year you attended school?
So obviously you just fill in some random string as the answer, but immediately after it you had to check a box that said that you swear under penalty of perjury that all information you put into this form is accurate... I'm sure that was intended to apply to the I9 stuff but technically it includes the secret question :[
This "protects" an account that has my social security number in it, among other things.
more secure random value instead: fd0987as0fh98a0b89safhsa
Instead of "blue" put "48d6215903dff56238e52e8891380c8f"
Technically, you're not lying. :-)
Obviously this would be less effective if people did this regularly.
https://www.pregnancymagazine.com/pregnancy/pregnancy-health...
> Babies of African American, Hispanic and Asian descent are usually always born with dark eyes that stay that way.
Reference isn't great but you'll see the same thing where this topic is discussed almost everywhere.
That said, it would be true for most white people.
I don't have a specific favorite movie or song. Lord knows what I entered into one of those boxes a year or two ago. Whatever it was, I bet it wasn't as secure as my password.
No biggie, the person telling you at length about the quirks of their first car until you mention what your first car was will happily try them all.
EDIT: like this https://news.ycombinator.com/item?id=14856834
These days they provide apps for phones where when you make a payment you have to open the bank app and enter your PIN to confirm the payment. Same for logging in to online banking (for which there are mobile apps as well).
Also, when making a debit/credit card payment online, you also have to confirm it with one of the aforementioned methods. You can't do anything with just the card details.
I can't believe some banks around the world use plain old passwords only...
If a bank doesn't offer something like that, but still happily does online banking, I'd take my money... anywhere else, even a mattress or the sugar jar.
It's not a bother since it's a 5 minute walk but I imagine that it would be hard for anyone other than me to actually do this, they'd have to show up there and convince the people there they are actually me (and some of these people now me personally)
I'd say that this would be the optimum in security.
Then the next point is realizing since they are "bonus passwords" anyway you might as well randomize them and use password fields. (In the Advanced Fields properties of an entry in KeePass, for instance, you have a key-value store and when you add one the "Protect in Memory" treats the value the same as KeePass treats other passwords.)
The final realization was that these questions should probably be labeled "Phone Passwords" and in which case use something like Diceware that produces easily pronounceable over the phone passwords.
If you do this, use a password recipe that generates a small number of words instead of a large number of characters. If you ever need to use the recovery questions, it will likely be by reading them over the phone.
One day I needed them and then I had to reverse engineer their security questions algorithm. Imagine the poor soles that aren't as technical to figure this out.
Well, about 3 years later, I had to complete a financial transaction over the phone. Out of the blue, the young lady asks me for my challenge answer. Oh my, I was so embarrassed by the quiet snickering and muted snorting when I read her my answer.
A plausible but incorrect answer is better I think, e. g. Q: What city were you born in?, A: Severodvinsk (a random town in Russia)
Ha ha! begins the fun,
From Severodvinsk to Minsk to Pinsk to Omsk to Tomsk to ME the news will run!
I got a tip from a friend when he had to produce past addresses and dates lived there. (Did I live on 123 Main St or 321 Main St?) Keep your credit reports and keep them handy. Refer to them for things you can't remember.
Once I got asked how old my mom was. Um... yeah, I'm honestly not sure of that. It was an age range and I guessed probably around (my age) + 25 and I got it right.
Look, webmasters, the simple truth is - I don't care. I have a default password that is very simple to memorise (and hence guess/hack), that I use for most logins, because frankly, I just don't care. Unless you're vitally important to my life (email, Facebook, backup, services that I use so often that they keep my personal/credit card data), your login/password is just an annoyance for me, as is your password security policy.
I commend reddit and webshops that allow "checkout as guest", that recognise this.
I once registered a Reddit account that had the same password as its username. After my first post, the account's password was changed and it started posting spam.
The only explanation I have is that someone was crawling the latest posts and trying to crack new accounts so that they have a legit first post and registration IP address to avoid auto-moderation.
Or, for example, a forum that drops all rate-limits once you are 1 year old with 1,000 posts. It now may be attractive to crack trusted accounts so that you can send mass PM spam. Or imagine if a moderator gets their password cracked.
So it's not necessarily just in the best interest of the platform, but also everyone that uses the platform. Though that's no excuse for particularly annoying password requirements.
For each user, just store a unique token and secret in local storage. That's their identity and password. So long as they log back in using the same machine (and they don't log out or are in incognito mode or whatever), they're good. For most sites or apps, this will be good enough for 90% of your users 90% of the time.
Now if you want to enable logging back in on another device, just ask for an email during your sign up. Then, when your user logs in from another device, you can email a login link that resets a new token / secret. Maybe a little more inconvenient for the user than just asking for a password, but it's a fairly minor inconvenience and it saves you from having to deal with storing passwords and worrying about screwing that up.
Plus it removes a step from your first-time sign up process! Which probably matters more than ease of re-logging in from another device.
There are plenty of sites out there with unnecessary registration requirements. I don't mind setting a weak, throwaway password on those.
He'll care plenty if his hacked account posts a threat against the president and he gets a visit from the secret service.
Remember the LastPass debacle?
Was there an actual debacle at some point?
That's all fine if you're a perfect robot. It will turn out that you aren't, though.
You could let one of your important passwords slip to a compromised dumb-password site by mistake; you could fail to appreciate how important a dumb-password site had become to you until it was too late; you could just make a human goof and set up PayPal (or what have you) with your dumb password.
But your personal ability or inability to get this stuff perfectly correct forever is kind of beside the point when you're setting policy. In a population of dozens, mistakes will be made. In a population of millions, mistakes will be legion.
If more organizations followed this guidance, it would make password systems easier to implement, easier to use, and more secure for everyone who did care. It wouldn't effect your practice in the slightest.
A upset love interest, a border control agent, someone who disagrees with you on Twitter, the police, a frustrated colleague, children with too much time on their hands, trolls, hackers.
None of these adversaries may be something to worry about today, but they might tomorrow.
We can all aspire to be bland enough to not be targeted, but I'd like to have that insurance policy in place just in case.
For example, imagine a typical user who tries to choose a password:
User: I want my password to be "monkey"
System: Sorry, that password is in the dictionary
User: OK, I want my password to be "monkey1"
System: Sorry, that password is on a list of exposed passwords
User: Grrr! OK, I want my password to be "monkeymonkey"
System: Sorry, that password is on a list of exposed passwords
User: Grrr! OK, I want my password to be "monkeyfuckyou!!!"
System: Sorry, that password is on a list of exposed passwords
User: Screw this, I'll just sign up with one of your competitors.
Software industry is in the same boat regarding this as car manufacturers were decades ago, i.e. it was "more profitable" to make cars that killed their passengers in every other car crash, since people were just making the very rational choice of buying the cheaper rather than safer car.
That's why I think there should be more focus on the point that users should never produce passwords themselves, but leave that job to a good random generator. This is also something I missed from Troy's otherwise excellent article. What is the point of using a password manager if you only use it to store your weak passwords?
I also believe the argument about passwords being memorable is a red herring. It is possible to remember a low number of sufficiently long truly random passwords. It takes effort and it is risky, but it is not impossible. Producing a good password without the help of a random generator on the other hand is simply impossible.
Well, that actually works out (except that the password is too short to survive brute forcing), because I then log in with that, do my business, and move on. Next time, same thing happens, "forgot password".
Which presents a much better authentication flow to my mind. Nevermind passwords at all; just focus on whether they own a particular email account. If the email account gets pwned, the attacker can likely log in with them anyway (and if that's an issue you need 2-factor).
So rather than force a password at all, send them a verification email, and have that immediately give them a token. If/when the token expires, have the login window require their email address, and send them another link that, when clicked (in the next X amount of time) will log them in with another token.
I know for me that would mean -every- account I have is suddenly 2-factor (since my email account is), they all have strong security (since my email has a long, complicated, hard to brute force password that I keep only in my head; it's the only one like that), and I'd stop having to rely on a password manager.
Curious if there's any obvious flaws that I'm missing.
The obvious flaw is that email is not instantaneous.
https://luxsci.com/blog/why-email-is-not-instantaneous-and-n...
You just produced one: pagpwthoargotohisi
The scheme you applied is well known. Making a wordlists from every sentence of the HN dump should be doable. And why stop there? Project Gutenberg, the whole Wikipedia and other Wikimedia projects like Wikiquote are just a download away.
A project I'm currently working on is facilitating the Google Ngram database for password cracking. I already generated almost 500 GiB of wordlists but haven't measured their success rate yet.
[1] Good wordlists have a success rate around 70% against the common leaks. Running one of these lists against a set of fast hashes takes less than an hour on a plain average business notebook.
[2] Assuming a fast hash, possibly salted. Slow hashes like bcrypt, scrypt, argon2, etc. are another story.
thspapaihp tsiwkbwaaioaes hdybadopihwyawnp famhbmompaaayznxwptx iycuwaatoaesiwjwlpywncm pciaartccwtmiateciatmpmtpeh
If the protection is adequate is up to you, but as your phrases get longer they quickly get impractical and memorizing and entering will get error prone.
>The scheme is well known, but what attack against it outperforms an exhaustive search?
Everything that is not truly random has a pattern that can be exploited to outperform exhaustive search.
>How do you build a database of poetry I haven't written yet and will never publish? Frequency analysis may help, but many of my poems are about a yellow zebra named x-ray who plays the xylophone. If you come up with an attack that outperforms an exhaustive search, I will just write longer poems.
Per position markov chains are one way. The point is, that as long as it isn't random there is a way to improve on simple brute force.
>You will never catch me. Password cracking is an arms race. The crackers can't win.
Cracking a single password is always hard but in a spear phishing attack there are often better ways anyway. Cracking passwords en mass is a different story and looking at the success rate for cracking passwords from leaks I'd say the crackers already won. There are also arguments why mass cracking gives an edge to the attacker [1].
>The math is against them. Every character I add to my password makes their problem exponentially harder.
Longer passphrases quickly get impractical and as long as the character you add isn't random there is a way to guess it.
>thspapaihp tsiwkbwaaioaes hdybadopihwyawnp famhbmompaaayznxwptx iycuwaatoaesiwjwlpywncm pciaartccwtmiateciatmpmtpeh
1. Good luck typing that without mistake.
2. Look closely on your passphrase, don't you see the patterns?
[1] http://www.openwall.com/presentations/Passwords12-The-Future...
yeah, and here's the problem. Security is at complete odd with user friendliness. Two-factor auth is amazingly secure, until you've lost your second factor.
User: I want my password to be "monkey" System: Sorry, that password is in the dictionary. May we suggest one of these strong client side generated passwords? ...
User: OK, I want my password to be "monkey1" System: Sorry, that password is on a list of exposed passwords. May we suggest one of these strong client side generated passwords? ...
> In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed.
(26 + 5)^12 = 7.88 x 10^17 < 26^(12 + 5) = 1.13 x 10^24
> 26^12 = 9.542895666×10^16
You could say adding 5 special chars "cheaply" doubles (formally) the search space without affecting how many chars users have to memorize.
To be fair, there are good reasons to assume that even long user-invented passphrases are no longer secure enough against offline attacks, especially when the keystretching algorithm is nonstandard or does not even use salt.
{lWfcM@Ko|u?;=hcYZr
> Error!
> The password is too weak. A good password must contain at least one digit, one uppercase and one lowercase letter.
Their requirements actually reduce the entropy here haha
But you don't know which slot has the special character and which has the number, and that choice expands the search space again (agreed not mathematically the same as with no restrictions, but then again users don't necessarily explore the whole mathematically available space of passwords).
I am a big fan of password managers, but I don't think there is a need for them, because WE ALREADY HAVE ALL OUR EGGS IN ONE BASKET: email.
If someone gets access to your email address then they have effectively access to every single service you signed up with that email. Therefore every single service might as well just use Google/Hotmail/Microsoft/etc. to authenticate their users instead of building their own login system and asking people to come up with a new password which forces them effectively to use a password manager and yet another place to store all eggs in one basket.
The password to your email account == the password to your password manager.
If we would all just rely on Google/Hotmail/Microsoft/Facebook logins then we would be even more secure then everyone having to use a password manager, and it would be a much better user experience. Also I am pretty sure that Google + Microsoft + Facebook have a lot more talent + resources to secure their accounts then every new service which pops up every day. Let them do the security and you focus on your actual business value...
1. Not everyone uses those email services. Indeed, for a certain subset of users (especially on technical forums like Hacker News), using them is seen as opening yourself up to unwanted surveillance.
This means tech forums relying on such a system are potentially driving away a decent portion of their userbase.
2. Not everyone wants to use the same account details. For instance, if I join a site with a more professional audience, my current username (and my email one) may come across as awkward or robotic. If I join a fan forum, I might want a username based on the game or show. Etc.
3. A lot of people want to keep their online identities seperate for security reasons. I mean, do you really want to use the same email for a dating site as you do your bank? Not really, but tying the login systems of each site to Gmail or the likes means you've either compromised said privacy or given yourself another Gmail/Hotmail account to memorise the details for.
4. It encourages centralisation. We've already got a problem with a few large services having an untoward amount of influence online, and having their login systems used for numerous other sites only makes that worse. It means if they decide your site is against the rules or 'hate speech', your users can't log in.
So nah, I'd rather sites didn't use third party authentication. It has too many drawbacks.
re 2.: If you don't want to use your private email for everything, then you already must have another secondary email, because there is literally no registration process which you can get past without an email. So just use the email which you find appropriate for a given website.
re 3.: Same as 2. You must have any sort of email to register anyway, so whether it's your primary email or your secondary "anonymous" email, it's still the same principle.
re 4.: Not doing something smart today, because there could be potentially a futuristic abuse scenario in some point in the future is not smart. Do what's best today, if tomorrow all email providers turn evil, then re-introduce your own login system, but you'll still need these email providers to verify your users.. so not sure how far you will get... but anyways.. this is a non-existing problem today and probably never going to happen. So why degrade experience and security for a Utopian future?
So yeah... I much rather use a secure and convenient auth system, because it has way too many advantages and we already rely on it, we just don't admit it. Might as well go the full length to get the best experience from it.
Imagine every password for every one of your users is published...can you identify people? How would you clean up the mess? Imagine a malicious person logged into EVERY one of your user accounts and tampered with them, changed email addresses, etc. Can you identify it? Can you clean it up? Can you prevent it from happening again?
If the answer to any of those is no...then you're sitting on a time bomb.
Start with the assumption that the username and password is convenient but unreliable, then move forward with actual security.
A better way is to use a scheme that hashes your username, service name, and master password to generate a password. A problem is that this doesn't always comply with the arbitrary demands on your password.
This is why these arbitrary demands need to die: they make the only way to securely and conveniently access accounts from different devices impossible.
Another downside is that changing master password means you need to change passwords for all sites or have multiple master passwords.
Another is that an attacker can use the knowledge of your password on site A to bruteforce your master password offline.
And so on...
Re. portability, KeePass and its siblings are compatible with every major platform.
You can even sync your database to all of your devices by storing it inside an encrypted volume for extra security.
This might be a concern if you're the victim of a state-level targeted attack. That's not a threat most of us have to deal with. Hackers aren't likely to spend a lot of effort cracking John Doe's password list; they want to steal a few million password hashes and sift out a few thousand easy or re-used ones.
Your other points about the weaknesses of the scheme stand. Still, if we could get more users to use not-terrible, not-duplicated passwords, even with a flawed scheme like this, overall internet security would improve immeasurably.
[0] https://www.theverge.com/2012/8/6/3224597/mat-honan-hacked-a...
Did those attackers guess or compute even one password at all?
There are many types of targeted attacks on passwords that don't come close to including state-level actors. Divorces. Corporate Espionage. Any one of the people on Judge Judy who posted information online about their co-workers.
With this scheme ANY site where you register can attempt to brute-force your master password offline. I fail to see how it's a good scheme.
Let's say you're master password only uses letters, numbers, and special characters. Just counting keys on my keyboard, there are 94 such characters. You should pick a random sequence as master password (very important).
Let's say you use the Antminer S9 (which can compute 1 gigahash per joule). For ease of analysis, let's say you can recognize the master password instantly. Also, say we're paying $0.2 per kwh. Then we can define the average cost c of finding the master password as a function of the master password length l: c(l) = 94^l/(1.8*10^10)
c(5) is about 40 cents, c(6) about 40 dollars c(8) is more than 300k, c(12) = 26e12
In comparison, the estimated amount of money in the world (in 2009) is 52e9 dollars. By the way, this is if you use a single SHA256 hash. You can make the hash arbitrarily expensive by iterating (computing h(h(h(master_pass)))).
The one and only argument against using a master password that is used to derive passwords is the single point of failure. If someone catches you typing your master password on video, you're pretty much fucked. But I guess this is the same for password managers.
There is still some truth in your arguments. I'm curious what you consider a good alternative?
How does one even calculate H(username|service name|master password) on an unfamiliar machine that might not have a decent scripting language installed on it? If you asked me to do it on my father's laptop, for example, I'm gonna have to download Python first.
Just spitballing which systems I would realistically want access to passwords on, at a minimum, includes: personal desktop, personal laptop, tablet(s), cellphone(s), family (parent, sibling, in-laws, etc) computers, office desktop, office laptop.
In my case (many cases?), the latter two prevent software installation, so I would need to manually type from a manager synced on my cell. Which really is no different to what is required for 2FA - just a longer character string. Overall, a some setup and synch related inconveniences but not to a damaging degree, which is why I think this is more a matter of perception - once you think through where you're typing passwords it appears less of an obstacle.
Cellphone and tablet I install the relevant app once and am done.
Either way, web access to the credentials isn't uncommon, though you'll need a device for 2-factor confirmation it's you.
For family devices...I wouldn't want to log into them. I don't trust their security sense and don't want to risk compromising my stuff because of their mistake. Why would I anyway; I have my cellphone on me, at minimum; I can access the account there.
I don't know about other Password Managers, but LastPass lets you access your vault using any web browser. So long as your network doesn't block the LP site, you can access your password manager from anywhere.
If I need immediate access to any other site and I don't have access to my password manager, I'll just trigger a password reset and check my email.
If it is a password I need to type, I use diceware "Correct Battery Horse Staple" style passwords. If I don't remember the password, I always have my phone, where I can retrieve the password from 1Password. There is no relationship between my different passwords. As long as my password vault is secure, so are all my passwords.
With your system, if I learn your master password and hashing mechanism, I basically have all your passwords.
On the other hand, if you take any other approach, you place either confidence in the security of a service (1password), or you store passwords somewhere. In both cases, you have a problem when you can not retrieve the passwords anymore.
If 1password is hacked or simply offline, or your phone gets stolen, you basically lost access to all services.
Security through obscurity. You're essentially just using the same password on every site now.
If you use a sufficiently good hash function with a salt to stop rainbow table based attacks and key strengthening for good measure, then an attacker who has one compromised password of yours isn't going to be able to reverse the hash to find what your source password is so that they can generate new per-site passwords using it. That is assuming they even try: how would you know that an arbitrary string of characters was generated that way rather than just being randomly picked by a password manager?
Of course all your accounts are compromised if someone knows your master password, but that is little different to an attacker getting your pass-word/-phrase for an online password manager that doesn't use some form of 2FA.
This is not a cryptographic attack on the hash but on the text that is being hashed.
These are two different classes of attacks, both being real-world attacks. The attack being discussed is against a suggested formula to generate passwords.
From the top of the thread, "a scheme that hashes your username, service name, and master password to generate a password." Discovering the password by determining the inputs to the hash function is all that is needed. This is the case even if a different type of function is used instead of a hash.
Apologies, if I gave a different impression.
Introducing a good salt would stop that but then the salt would need to be stored and managed somewhere (securely synced everywhere you might need to regenerate a password - it can't be a public value or you are back to square one with the dictionary attack). You could also introduce a CPU and memory intensive key derivation function to frustrate the brute force attack a little but that is a race you won't win if you need the function to work on a low resource device and the attacker has a large cluster of processors and/or plenty of time to work with.
It would protect against password reuse attacks even without the salt: if site1 stores plain passwords and leaks them then getting into my account on site2 becomes no easier than it already was if I had different passwords for each site (we are still looking at a brute force dictionary attack against the master password) so the scheme could work if the user has a sufficiently complex master key (and never needs to change that key). Making the master key complex enough but memorable is the challenge there, back to one of the core password related problems but at least with only one (or a few) to remember not one per account. Changing the master key once you believe it has been compromised would be quite some hassle in a similar way to if your master password for a service like 1password were compromised (worse: with a service like 1password you at least have a list of accounts to work down but with this scheme you need to remember them).
An interesting though exercise, but I'm probably overthinking an unrecoverably weak idea...
This is a very bad mechanism to create passwords that will create severe security vulnerabilities. You are adding complexity and false-security without benefit.
Passwords are a secrecy mechanism, not a formula mechanism. In your method, all one needs is the formula, then all passwords will be disclosed.
The suggestion might then be to interject a secret with enough entropy into the text being hashed. But, that is no different from a secret password itself!
I'll add docs and updates if people give a shit. The passwords.dat file in the resources folder is the top 1m most common pws that I compiled from a number of lists available at the time.
I implemented a redis-backed instance of the above common-password bloom filter in a sample Spring app which I was using to show off some features of spring security to a dev (I work in AppSec). You can see the policy and redis config here: https://github.com/milo-minderbinder/spring-ref/blob/indev/s...
And you can see an example of how to wire it up to a Spring Validator here: https://github.com/milo-minderbinder/spring-ref/blob/indev/s...
And you'll find where it's registered as a bean in the SecurityConfig.java file in the config dir with the other Spring java-config classes.
If you want to run it, I dockerized the whole Shebang with docker-compose a whole back, which should be easy to run: https://github.com/milo-minderbinder/docker-spring-ref/tree/...
Hope any of this was meaningful to literally anyone in literally any capacity haha
Really though, a list of common passwords to block is such a small amount of data that it's probably best to just use an exact list. I can't see it being more than a megabyte or so.
I agree with you that Troy would probably be one of the best people to provide something like that. I wonder how feasible it is, that would be a really great resource to have available.
My only actual quibble/concern with this piece is in the "Notify Users of Abnormal Behaviour" section. I agree it's a good idea in principle to perform notifications, the only niggle though is that some common forms of notification are not authenticated in general, and in practice that particularly means email. I have only ever seen a few companies, even in the financial sector, that sign emails (and without that more aggressive automated domain anti-forging is hard too). At least from the stats I've seen on my own servers and for users I'm responsible for, "Notification/Alert" emails are an ever greater favorite of spearphishers & spammers. A lot of the major companies deal with this by using better authenticated purpose-made notification systems or even just text messages, but email still enters in, and if the practice spreads I'd expect to see a lot more places just using email. I think it's worth being careful about getting users trained into any habit that might lead them to immediately assume something from an unauthenticated source is real and should be clicked. This might be an area that'd be worth coming up with better standards and UI for as well.
There is a pretty clear path off of it, via physical token authenticated password managers. The only thing missing is a standardized and well popularized protocol for changing passwords.
I don't think it's that simple. After all, the basic tech to handle this stuff has been around for literally decades at this point. Even in terms of open source, projects like OpenSC date back a decade and a half (2002 or before). The problem has always been in terms of bringing the elements together into a standardized system that has a least a few major implementations with good UI, and gaining critical mass to kick start a virtuous circle of adoption, uptake, demand, and more adoption. It's not a technology problem. I've seen enough hopes raised followed by false starts or even flat out regression that I think it'll be a hard slog, though as the problem is only getting worse I'm hopeful we'll get there eventually. And even more, that once there is at least one good mass example showing people how things could be better there will be mass demand and we'll see a nice S-curve of adoption rather then linear.
It's not a magic bullet and not something a switch can be flipped on, but the status quo is terrible.
Sure, you can gave software U2F keys, but that's not commor or expected from what I understand.
I'm pretty sure he's doesn't work at Github, though :)
It also ties a lot of identities together making it not Angkor solution for many people.
Aside from the space consideration already mentioned, if I had to surmise, I'd guess it would be faster to process because we're skipping the encode/decode steps unless we are explicitly "importing" or "exporting" the hash, and less chance of making mistakes to encode/decode through Base64 before doing anything with the hash.
It is marginally more of a hassle to debug in a live production environment, though. When you are troubleshooting, grabbing the binary representation and running it through a Base64 decoder is annoying. Doing this from inside a mass file search to look for all instances of the same hash can be a bother.
I suspect we're storing as Base64 everywhere because so many hashes are held in XML files, and the standard strongly encourages storing binary within XML as Base64. Once they are doing it in an XML file somewhere, I gather lots of teams make that the canonical representation everywhere, even in a database when it isn't strictly necessary.
In practice I doubt that it makes much difference in terms of performance as hashing is way more expensive than base64-encoding. The rant is probably more against the misunderstanding of developers.
And if you suggest it's for performance, a b64 decode is going to be a tiny fraction of your CPU usage compared to bcrypt.
I use LastPass but I don't like using the password generator because I want to be able to log in on mobile or other computers when necessary, but I don't do so enough to justify signing up for a subscription (I dislike subscription models) that would allow me to access use it on mobile.
I wish I could just use giant password strings on all of my sites.
People take for granted that an organisation can just hook into a bunch of paid external services, GeoIP, Browser/Device Database, etc. First off, there's a great many organisations who cannot or will not be able to use an external GeoIP database for example, and even if they could how is a threshold of "abnormal" determined?
I too love Facebook's implementation. How do I make that without hooking into half a dozen paid external providers? I'm legitimately asking, because this seems like a "research team and five years" type of issue.
- Inform users of unsuccessful login attempts since their last sign-in. This can let them know if someone is trying to attack their account.
- Notify the user if they login from a new browser. You can record information about the client (user agent plus other identifiers that are visible server-side) and then notify the user when connections are made from new systems that haven't been seen before.
- For GeoIP there are basic datasets that cover things like country of origin that are generally available for free. You could use one of those to note the customers general country of origin and then notify when that changes.
None of these are flawless of course, but they could provide some basic means to help users protect their accounts.
As much as I hate passwords, I don't think we should get rid of them without replacing them with something else...
I just put the link here to get some feedback. This is what replaces the passwords.
i.e., when changing your password: "You used this password too recently, you can not use your last 20 passwords"
Back before I used a good password manager setup, I used a mental algorithm of [base password] + per-site modifications. These were saved in Firefox and I'd sometimes forget them when I wasn't on my normal device. If I needed to get on to a service (eg, email) whose password I'd forgotten, I'd reset it, then reset again, back to what it was, when I got back to a place it was saved.
At some point, gmail prohibited this, and I had to update all my passwords whenever I needed to reset. The result was the same as forced password rotation: I just started using more memorable (less secure) passwords.
That said, there's definitely measures Google could take to mitigate this effect. For example, drawing from the article, there could be tiered access control, where one tier (eg, 2fa but no pw) lets me get some limited access without changing the password. Then there would be no legitimate reason for returning to an old password, so such a policy is not harmful.
Why do I need to change passwords every thirty days? Because it's one of only three questions our risk assessment auditors actually ask, and "failing" is bad news.
If we accept we don't need to rotate passwords arbitrarily, there's no reason to have rules like this - it's more secure and less effort to not retain the last 20 passwords.
I guess for one; not everyone wants to buy and carry a key. But we're at the point where you have to have a password manager anyhow, a token isn't that much more of a burden.
Well, you are favoring U2F, which is a _specific_ _implementation_ of 2FA. U2F isn't being used generally, because it isn't a general purpose solution.
> I guess for one; not everyone wants to buy and carry a key.
This statement is the problem with looking at specific implementations to solve a general problem, instead of looking at all the solutions.
There are many solutions, not all of which even use physical keys fobs. RSA is a straightforward example of why a 3rd party shouldn't automatically be trusted for auth mechanisms.
> But we're at the point where you have to have a password manager anyhow, a token isn't that much more of a burden.
The burden isn't just a user side issue about carrying a fob. For general password replacement, key fobs will get lost. Passwords are a burden to the user, having to pay or deal with key fobs and their replacements will be an even greater burden. You are proposing to solve the auth problem by causing many users to stop using websites.
Unfortunately, there are also issues with soft tokens. There are still applications that only use the "first soft token" in a list of soft tokens owned by a user. Plus, soft tokens are quite amenable to being copied.
There are also many banks and credit card issuers who have consciously chosen various forms of 1.5FA instead of 2FA. In many cases this is a valid solution, a form of dual sided auth that works across all clients.
Security-conscious users can push for 2FA on services, but we probably won't hit it being mandatory any time soon.
1. Your profits come directly from your users
2. A password crack can result in them losing a significant amount of money, and
3. This happens often enough that it offsets the userbase losses of 2FA
If your user accounts are important enough to let them lose a large amount of money, your users are probably demanding better security from you already. The real blocker to 2FA are services which rely on being convenient, and make money off their users being users e.g. social media.
I disagree. Author pointed out "all eggs in one basket" issue, but it doesn't look like he completely understands the whole problem. The main problem is that passmanager holds a lot of metadata.
For example, you use unique password with high entropy for every service you use. Once attacker gets your one master password (through zero-day or just by watching you type it), potential damage is massive. He doesn't have to try to find where you are registered, password manager will tell everything, about every single account and possibly more; some people even store credit card/banking info in passmanager. At that point it's over, you lost.
"... if (password manager) gets compromised it's going to be bad news. But this is an exceptionally rare event compared to the compromise of an individual service which consequently exposes credentials."
This is not an argument at all. Let's consider the situation when individual service gets compromised. Attacker has thousands of salted hashes. With good hash algorithm, he have to spend considerable amount of time cracking every single hash. He doesn't target you in particular. You are just one of many. If attacker cares about you, after cracking hash and getting your password, he has to do a lot of research (trying to find other sites where you used that password and hope you didn't change anything there) to make any use of it. Objectively, he doesn't actually have much. So going after popular services you use, just to get your password, doesn't look like a good attack vector in the first place.
People should know, that password manager is just a glorified notepad file with one password. By using them you are trading safety in situations when attacker targets you, for safety in situations when attacker targets someone else and you are just a collateral damage. If you must, use them only for information you don't care to lose.
Of course there is a trade-off with the master password, but on the whole, I'd say it's a definite security win, because the user only has to remember one strong password instead of many, and an attacker only has an advantage if they've already won anyway.
The main difference is amount of information attacker will get. With passmanager, he will get everything instantly once you type master. With manual typing, he will have to wait until you tell him about every single account, one at a time, so it's a bigger risk for him to get caught.
And password managers, in general, give average Joe false sense of security. So he starts storing everything in them. Bank accounts, credit cards, you name it. And once he gets hacked, amount of damage he receive will be much greater.
If the alternative to not using a password manager is password reuse or enumeration (sup3rMan!_gmail), it becomes for attackers even if they're not explicitly targetting you, as they can run patterns against the whole DB against Gmail/Hotmail/Facebook etc
>This is not an argument at all. Let's consider the situation when individual service gets compromised. Attacker has thousands of salted hashes
Wait, who said they are hashed? Perhaps an irresponsible webmaster stored them in plaintext. Now, even if that service itself isn't very important, it's likely that certain users re-used the same(or a similar) passwords in more important services, such as Google.
Now, while you're right that using a single master password does pose a risk, there aren't other viable solutions to secure password authentication, unless you; Memorize a strong password for every service that you use Never share passwords among the services Don't store saved logins in your browser Never link your services to your email (because then if your email account is pwned, your accounts in those services would be pwned too, another "all eggs in one basket" issue)
If you can do all of the above, then great, but most people can't.
I keep hearing this argument and i think people who use it just don't understand why password has to have high entropy (e.g. strong). It's not to stop attacker from bruteforcing login page (nobody is doing it nowadays), it's to stop attacker from cracking hash, if he gets it. If password is unique, it doesn't have to be strong.
>If you can do all of the above, then great, but most people can't.
And this stuff again... "Security is hard, just use this password manager, dum-dum." All you have to do, is divide your accounts into two groups: accounts you care about and accounts you don't. Most people would not have more than 4-5 accounts in the first group. Create and memorize strong password for them. For the second group, you couldn't care less, so use passmanager, that is the only good use case for it anyway.
A bit off-topic perhaps, but can a keylogger really grab your master password as you type it? 1password and OSX has secure entry for entering a system password, no?