Show HN: A simple “stateless” password manager for Chrome
stephanboyer.com
stephanboyer.com
However, the gigazillion rounds are not for nothing. That is the defense against brute force attacks, which could otherwise crack passwords even if they are random.
Deleted comment
Examples:
syntax: gassy salt base [password length || 16]
gassy spoiler news.ycombinator
gassy email@personal.me home_email
gassy name@ work.com 32
I know it's not ideal, but it served me well so far! :-)
"If a generated password is ever compromised, you don’t need to memorize a whole new secret key and update all of your passwords. For that service only, just add an incrementing index to your secret key. For example, if your key was bananas, just use bananas2. If you can’t remember which iteration of your secret key you used for a particular service, simply try them all in order."
In particular, you don't have to use the same secret key for all websites. It's okay to slightly modify one if that password is compromised.
My bank requires me to change the password every 3 months or so and I only need to change on digit in what I remember and they see a whole new password.
It's a great benefit to me and to overall security.
How secure is it overall? Somewhat more secure than just using a single password for all sites and better trust compared to using a cloud based password storage.
Hopefully this happens infrequently enough that it's a non-issue anyway.
The extension doesn't force you to use one master password, and it doesn't have to be a dictionary word, too.
I think adding options like an auto expiring password (adding the month or year etc as a salt) can improve this further. But I like the idea in general.
The #1 benefit of a purely stateless password manager is that there is no password database, so your password database cannot be compromised.
The drawback, as others have mentioned, is that it's difficult to use strong salts without keeping some sort of database. Changing passwords also becomes a big hassle.
But what about a compromise? Keep a database, but only store the salts in the database. Generate the passwords on the fly using the master password and the domain-specific salt. Now you can have your cake and eat it too! If anyone steals your database, all they have is a bunch of salts. You probably won't even have to keep it encrypted.
Keeping a database will also let you add some of the following features, which I consider essential to any modern password manager:
- Remember the username for each website. Some websites ask for my email address, others ask for a simple handle, and I shouldn't have to remember which is which.
- Manage more than one account for the same domain, each with a different username.
- Change the password for only one website, without changing the master password, and without having to use a silly suffix. Just change the salt for that website. (This is one reason why it's a bad idea to use the username as the salt. The salt should be random and easily changeable.)
- Remember password restrictions for each website. If your bank limits passwords to 12 characters, you can store this setting in the database and automatically truncate the hash to the desired length. If your school doesn't allow special characters in the password, also remember this setting and skip non-alphanumeric characters from the auto-generated hash.
Until now, most of the features I listed above have only been possible with password databases. But if you think about it, there's no reason not to go the hybrid route.
Deleted comment
From another Ask HN[0], I learned about bpasswd[1] which does bcrypt and allows the cost (iterations) to be configured. That looks pretty cool.
For me, I chose to go with a hybrid approach and wrote hash0[2] for my less important passwords (important ones live in KeePass). Hash0 does 100,000 iterations of PBKDF2 with salt from CSPRNG unique for each site. It stores the encrypted metadata (just the salt, length, symbol/no symbol, etc) at a location of your choosing (I just store it in my Google App Engine).
Would love to get more eyes on it and get feedback (See services.js for generation logic).
Benefits of hybrid are that:
- Allows me to use random salt
- Allows me to easily change password for individual sites (thanks for random salt)
- Allows me to store website's preferred password length and whether to use symbols or not
- Allows me to create mappings (so say www.twitter.com and account.twitter.com can use the same password)
- Allows me to store notes along with the metadata (e.g. what username I used)
- salt. To avoid rainbow table attacks. One could use the login/email as salt
- key strengthening function. Instead of repeating naively SHA-256 a few times, use PBDKF2 or even better, something which is also memory hard like scrypt.
Finally. What happens when the password requires to have upper case, symbols, x number of digits, min or max number of characters... If you think about it, some websites have conflicting requirements.
Re key strengthening: Agreed, but only salt-less schemes will work in this stateless model. Unfortunately they are few.
> Finally. What happens when the password requires to have upper case, symbols, x number of digits, min or max number of characters... If you think about it, some websites have conflicting requirements.
Addressed this in the article: "Some websites have certain requirements on passwords, e.g., at least one number and one capital letter. A simple way to meet such requirements is to append something like A9! to the generated password (and remember you did that)."
It would be great if there was a site ran by a widely-trusted body (EFF for example) that tracks the various password requirements and limitations of websites. That way password managers, such as this one, can query that authoritative database for the idiosyncratic password rules for each domain and generate a password of the maximum allowable length and with the largest possible alphabet.
However, it might be okay if one can provide their own hashing function. Like a JS function that takes the domain and secret key as parameters.
But, your suggestion of a JS function that take the domain and secret key is how the GenPass and SuperGenPass bookmarklets have worked for years (and the flaw in that method has only been fixed this year, I think).
Granted, fragmentation in this space is actually good for security, because now there are is a different hash for each password generating program.
This is one of those "only use it if you know what you're doing" things.
Firefox: https://addons.mozilla.org/pl/firefox/addon/password-hasher/
Chrome: https://chrome.google.com/webstore/detail/pawhash/adgekjfphh...
So, what's different about this from the SuperGenPass session Chrome plugin?
> SuperGenPass uses a one-way hash algorithm (base-64 MD5) to generate passwords. Specifically, it concatenates the master password and the domain name of the Web site (masterpassword:domain.com), hashes the result at least ten times (and until it satisfies the generated password requirements), and cuts the result to the desired length.
Yikes! MD5 is known to be broken, and 10 rounds of hashing is no defense against brute force attacks. Hashpass uses SHA-256 (not broken) and does 2^16 rounds of hashing.
To anyone reading here: Please do yourselves a favor and stay away from BOTH SuperGenPass and from this one.
They are nearly equivalent to using the same password for every website. A malicious website owner can derive your "master password" from the hash that you gave them and thereby gain access to all your websites.
That's an extraordinary claim. (I'm not gonna argue too strenuously about MD5 being somewhat dangerous in this context, as it is very easy to find collisions...slightly harder to find the exact passphrase, particularly if it is a very long/strong passphrase. A collision in this context is not enough to break the usage.)
Don't put words in my mouth, I never suggested anything like that.
In Bitcoin the private key is derived from the public key which is normally randomly generated and not provided by the user.
The browser 'password manglers' mentioned here instead derive it directly from the password provided by the user. That is a big difference.
Most users don't choose a password of sufficient strength since they are limited to printable characters and especially when they are required to type it in all the time.
This is why key stretching functions such as PKDF2 and Scrypt were invented. To make relatively bad passwords (which users are prone to choose) harder to crack.
Screwing this particular step up in a tool that wants to be a password manager (of all things) strongly indicates that the creator has no remote clue what he is doing and that everyone should stay far away from his software.
What does a good password manager look like if not this?
This lets the user change his master password without invalidating all stored passwords and the compromise of any single or multiple site passwords does not affect the master password in any way.
And since the password-file is encrypted it can also be trivially backed up and synced across devices using any untrusted transport (e.g. Dropbox).
As it happens, this is exactly how the common solutions (KeePass, LastPass) operate. This part of the wheel is in no need to be re-invented poorly.
Not having a database certainly has its downsides.
Re usability: I've been using it for a couple days now, and I find it pretty tolerable. It's nice to not have to memorize a new password when I sign up for something. I did change my master key once; it took about 5 minutes to update all my passwords. If you only do that once every few months or once a year, it's not so bad.
A <$1000 bitcoin (SHA-256) mining ASIC appliance is likely to be doing 1TH/s. Makes 2^16 rounds look kinda weak.
Do not use this, it's a textbook example of how to not do it.
This is not a new technique. In addition to the Stanford paper, there are several other implementations mentioned in these comments. It's a compromise, not a mistake. It is better to memorize one strong password than a dozen weak ones.
This isn't custom crypto. It's a well-known hash function that serves as a filter, transforming the passwords you would otherwise enter directly into a website's login form. It is no less secure than typing in passwords by hand.
Um yea.. "basically".
Except they demand an 'ultra-slow' hash function in that paper. You ignored that requirement and that makes your implementation equivalent[1] to using the same password for all websites.
You are wrong. Your analysis is based on the premise that an attacker might be able to compute "a billion hashes per second".
As I just showed you in my previous comment anyone with $3000 USD can actually compute at least 6000 billion hashes per second.
This means it takes about 11 days to crack a random 8-character alphanumeric password. Not 200 years as you claim.