password = base64.b64encode(pbkdf2(master_password + '/' + domain, b'', 100000+n, keylen=16))[0:16].decode() + '$1Aa'
'$1Aa' is to appease stupid websites that require a symbol, number, uppercase, and lowercase letter.
Truncation to 16 characters is to appease stupid websites that limit passwords to 20 characters.
I also use the same thing for the answers to all "security" questions online, where I just plug in the security question as domain. (They're basically de-security questions, since, you know, a lot of people in this world know what my favorite color is and what streets I used to live on).
I should probably use HMAC but whatever.
The only passwords I have that are not part of this system are my computer's root password, e-mail password, and bank account passwords; for those I just memorized random strings).
This system gives me the following advantages:
* Peace of mind that I don't have to trust a 3rd party, closed-source password manager
* No need to cloud-sync anything across machines. No need to access the internet.
* I can calculate my passwords without a database, so if I have to randomly reformat my machine while travelling I can still compute my passwords and login to everything I need to.
This is something that drives me up the wall. I understand that you have to impose some kind of limit on password length to avoid abuse, but there's virtually no reason to cap it at anything less than 32 characters. I think a cap of 128 characters is completely reasonable and likely to appease even the most paranoid of users-- it all hashes to the same size anyway.
Another thing that irritates me is when registration forms enforce max password length via javascript or maxLength, without describing the max length in writing somewhere on the page. If I generate a password and I paste it into that field, I have no way of knowing if it has been truncated or not. I can't count how many times I've registered for a website and then had to immediately recover the password because of this. The time that stands out most to me is when this happened with my bank! Come on!
Pro-tip to any web developers out there: providing some kind of visual cue that the password I've entered is at the maximum length of the field (and that it was possibly truncated) is a good solution to an edge case that I feel is rarely considered.
1. it's not always clear what the domain is. Sometimes a company has more than one portal to enter a login. Now I have to remember which one I was using when I created the account. I can try to use the company name but that's ambiguous as well because sometimes the portal's or product's name is different from the company's name and now I have to remember what the "domain" is.
2. Different services have mutually contradictory requirements for passwords. You mentioned you add '$1Aa' to appease some websites, but I have encountered ones that have a no symbols rule, or some that have minimum length 12 while others that have maximum length 10.
I believe the most reasonable solution is to use a password manager.
My main objective is to eliminate personal databases.
My password "manager" doesn't automatically fill in passwords until I consciously ask it to.
But some amount of human oversight over those pull requests would be in order.
4. You will need a clipboard everytime to copy paste which is not very safe
Suggestion: Add a salt parameter to make it less deterministic, keep these salt in a personal database
On phones I just type it in after looking at it, or compute on my computer and punch into my phone. I can memorize a 20-character string for a short time. In the future I might make a device to plug in via OTG cable, emulating a USB keyboard, to enter the password into phone apps. Another option for phones is key injection using /dev/uinput which is accessible if you run Cyanogenmod.
Now I see why such a system works for you. Very few people can do that in case you didn't know.
By the way what do you do when you have more than one account or when the website wants you to reset your password (because they leaked it again...)?
However, this well known method has many flaws:
* very hard to satisfy all site-specific password requirements (need symbols, no symbols, at least 8 characters, at most 8 characters, etc. etc.)
You can work around this by storing site-specific requirements, but then you need to sync again, basically.
* very hard to version: if LinkedIn screws up again and you need to reset your LinkedIn password, but don't want to replace all your other passwords by changing the master password, what do you do? You can version by including a version number or so pre-hash, or increase the number of rounds (as the GP suggests) but then you need to sync the version number (or remember it or try), so you're back to square 1.
* Also, might want to use Scrypt or Argon2 or so instead.
There are other problems. See related HN discussions for these frequently suggested storage-less "password managers":
For less-sensitive sites (i.e. things that aren't going to screw me over if my account is hacked), I just save the computed password into the Chrome password manager. The computed password can't be feasibly used to get my master password anyway.
For many sites it's possible to stay logged in with a session cookie without saving the password.
What does this give you that, say, KeePass doesn't?
If only our ancestors didn't so royally screw that up.. they took the brilliant public-key crypto and even just through the bazillion different encoding schemes and various "cert store" madness have made its use entirely untenable. The whole "the service can't know the password" problem was entirely solved and look where we stand today.
A sane certificate management UI (not hidden beneath 5+ clicks, and not full of useless distractions like "software security token" that scare users away), key escrow protocol (opt-in), transparent certificate sync (yes, has downsides, but no worse than password sync), and some JS APIs to manage certs - that can do miracles. But that won't happen.
What's good about TLS is that it's ubiquitous and you don't need anything special to deploy it. Got nginx, Apache or Caddy? Add a single directive (e.g. ssl_verify_client for nginx) and you're almost there, all the validation is already implemented, just tie the keys to your accounts system.
It is new (tiny and well thought through) API but nobody used client certs anyway, as we found out in this very thread.
Also, I think Chrome is in the process of removing support for <keygen> (and client side certificates in general?), so whatever opportunity existed for making this common has now passed.
-I had to refresh certificate once per year, which is very inconvenient, as I would go to startssl.com once per year total
- Half of the time something would go wrong with keygen in firefox and it would not remember my certificate at all. This is when you discover that all the security is simply bypassed when you send email to support.
- And worst of all, it was not very secure at all -- a malware on my computer would totally steal a certificate and keysniff the password for it. Compare with Google Authenticator or SMS auth, where I would be safe as long as my cell phone is not compromized at the same time.
Firefox still works. No idea if people use it for auth, but it is popular when requesting a certificate.
But does it really improve security that much? If password is short, it's still gonna be quick to crack.
Only if the cracker is brute-forcing instead of using common passwords mixed with dictionary words, and if the brute-forcer thought to implement emojis. Given how many emojis there are, it would by psychotic to include them in a brute-force attack unless you already know the person used emojis.
Unless you pick the passphrase for them, you're not really gaining the advantage of the search space size.
PS. No I don't use it anymore. And yes xkcd 936 was my inspiration.
Initially we just wanted to implement zxcvbn and be done with it, but due to some in office politics, we had to take it a step further and do a password policy review; our federated login across so many systems resulted in some really bizarre password requirements, so we wanted to simplify it and push users towards passphrases for more secure passwords.
The idea I was pushing was that we'd basically just spend an afternoon coming up with as many benign questions as we could to get a list of about 400-500 some questions, on account creation, the user would be queried for 3-4 of the questions randomly, and a system would generate a passphrase based on the answers provided with a bit of security fuzziness (maybe a substitution or two, random order, underscores or spaces, etc) to the passphrase to ensure it met what zccvbn considered secure.
I'm not a security guy as much as I'd like to be, so I don't quite know what harm there is in such a system, but it seemed like a good idea at the time. The biggest problem as we could tell it would be the user would forget the password or be annoyed by long passwords, and even if you knew the entire list, it seemed unlikely you could figure out which questions they got and in what order, and the number of questions seemed to prevent even educated guesses by spouses/stalkers.
It was ultimately shot down by politics because the President of the University couldn't come up with a valid password using this system. (he insisted he must be able to use his password scheme, which it turns out always included the university mascot name, which was part of the forbidden list) Currently I think it just runs with the simplified rules requiring at least 8 characters and meeting a security rating of at least 4 per zxcvbn.
If I want to log in, an e-mail is sent to my mail, and an optional 2FA on my mobile.
If my mail is compromised, all the other passwords can be reset anyway.
I think we need to get away from the idea that people should memorize passwords at all. The default should be "generate long password (or encryption key for sites that support it) and put it in your browser's password manager". You only need to memorize the main passphrase for your system-level encryption.
If maybe 5% of the accesses the site requires authentication (the other 95% passthru cause you have the cookie) - make that 5% use a text code to your phone. EDIT: App on yr phone, not an SMS
No more passwords.
https://www.wired.com/2016/06/hey-stop-using-texts-two-facto...
There's plenty of stories around of spear phishing attacks involving attackers taking over the victim's phone number. Mobile operators are notoriously vulnerable to that sort of shenanigans.
I'm not sure about Microsoft, but Google supports several other 2FA mechanisms in addition to SMS.
1. every site to obtain some automatable way to send text messages, which can get mildly expensive,
2. people to acquire at least one burner phone for authentication because they don't want $randomwebsite to have their real phone number, and
3. users to give up some degree of anonymity because the country of origin can't be hidden behind a proxy, as the phone number gives it away.
This sounds like an overall loss for everybody to me.
hunter2-esque "how do you know my password?!" would be rife!
It implies that the system knows plaintext password. Even if the system deletes the password and keeps a hash, it remains the problem of distributing that password to the client in a secure way.
No it doesn't, the password can be generated client side. I know that client side code is not safe, but the purpose here is to protect people who are not tech savvy enough to figure that out.
That's no different. It uses the same channel the user would send the password to it.
That is they get to pick a generated password (by the system) that is easy to remember. Maybe from 10 or so.
There are password generators that use multiple words but are really long (eg you have probably seen the new router passwords that are like this).
I have even thought maybe emojis might make for better passwords for some users.