Show HN: A simple “stateless” password manager for Chrome

Wouldn't you then need to sync the randomly generated salt across browsers? That doesn't seem so stateless anymore.

yes, that's exactly what stepstep said

I have made a CLI stateless password manager for myself once (still use it, actually) and I generally "solved" the salt issue by providing the salt manually.

Examples:

    syntax: gassy salt base [password length || 16]

    gassy spoiler news.ycombinator
    gassy email@personal.me home_email
    gassy name@ work.com 32
    

in the next step you're prompted for a password (with echo off). Also, it calculates a token based on the salt which determines in which way the password will be generated.

I know it's not ideal, but it served me well so far! :-)

As usual, purity is overrated.

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.

It sounds like you're asserting that Bitcoin is not secure because it uses SHA-256. i.e. a pass phrase that has been hashed with SHA-256 could be brute forced to find the master passphrase, thus, a Bitcoin private key could be compromised by a brute force attack.

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.)