
Show HN: A simple “stateless” password manager for Chrome - stepstep
http://www.stephanboyer.com/post/101/hashpass-a-simple-stateless-password-manager-for-chrome
======
a1a
Please tell me I am missing something. There is no salt. The hashing algorithm
is hence vulnerable to a simple dictionary attack. It does not matter if you
do a gigazillion rounds. Someone can still pre-calculate a list of common
passwords and then test that list against each and every user.

~~~
epimenov
and the best part is you can't change your password in case some website
becomes compromised and the hash is leaked. (without changing the secret key
and as the result changing all passwords on all websites).

~~~
stepstep
I tried to address this in the article:

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

~~~
ansible
And that then starts to negate the point of this password manager: having to
remember just one password.

~~~
baruch
I use a similar tool (pwdhash) and the benefit is not that it's a single
password but a single root password. I need only a few changes and very little
to remember for most sites and still get a unique password per site.

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.

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

~~~
dannysu
I pretty much wrote hash0
([https://github.com/dannysu/hash0](https://github.com/dannysu/hash0)) for
most reasons you listed. Would love more auditing if you're interested to take
a look.

------
anton_gogolev
Why do 2^16 rounds of a designed-to-be-fast SHA-256 when there are
deliberately slow PBKDF, such as scrypt?

------
dannysu
There are many of this type of hash function based generators, but pretty much
all use fast hash functions. The no salt thing also makes me uneasy.

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)
    

[0]:
[https://news.ycombinator.com/item?id=8753534](https://news.ycombinator.com/item?id=8753534)

[1]:
[http://www.alexhornung.com/code/bpasswd/](http://www.alexhornung.com/code/bpasswd/)

[2]: [https://github.com/dannysu/hash0](https://github.com/dannysu/hash0)

------
jackjeff
It needs to be improved to be secure

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

~~~
desdiv
>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.

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.

~~~
cm2187
Buy what if they change their requirements? Then you need state (when the
password was created).

------
lqdc13
Ok, the idea in general isn't good because most people won't use a good
password and also because now there's a single point of failure if someone
sees your password.

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.

~~~
kennywinker
It's still a huge step up from the all-too-common "use the same password
everywhere" technique.

~~~
lqdc13
not a huge one. Because now instead of testing just the common passwords, the
cracker would just have to double the amount of work by testing their hashes.

Granted, fragmentation in this space is actually good for security, because
now there are is a different hash for each password generating program.

------
prohor
Existing extensions for FF and Chrome using the same idea ; both use the same
algorithm so you can share passwords:

Firefox: [https://addons.mozilla.org/pl/firefox/addon/password-
hasher/](https://addons.mozilla.org/pl/firefox/addon/password-hasher/)

Chrome:
[https://chrome.google.com/webstore/detail/pawhash/adgekjfphh...](https://chrome.google.com/webstore/detail/pawhash/adgekjfphhgngpdoklolpjenmgneobfg?hl=en-
US)

------
SwellJoe
I've been using SuperGenPass for this for years. There is a Chrome extension
that is safe (from website snooping of your key) and a browser bookmarklet
that is not safe. But, I just use the mobile browser version in another tab
and copy paste since I choose to use Firefox. It's a little less convenient,
but not inconvenient enough that I've spent time trying to figure out how to
make a safe extension for Firefox.

So, what's different about this from the SuperGenPass session Chrome plugin?

~~~
stepstep
Just took a look at the SGP FAQ and saw this:

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

~~~
moe
No, SHA-256, the way you use it, is not "far too slow for brute-force".

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.

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

~~~
moe
_It sounds like you 're asserting that Bitcoin_

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.

~~~
SwellJoe
So, pass phase length and strength is the concern here? If a human were to
generate a reasonably strong pass phrase (say 25 characters), would that
mitigate the problem? (Certainly this is stronger than a memorizeable unique
password for every site, but I'm willing to believe I should do better.)

What does a good password manager look like if not this?

~~~
moe
A good password manager generates a new, strong, random password for each
site, stores them in a file and encrypts the file with a key that is derived
from a user provided password via one of the aforementioned methods (PBKDF2 or
scrypt).

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.

------
laurent123456
It's an interesting idea, but is it really usable? If you ever need to change
the master key, you'll have to update all the websites you are using, and you
won't even know on which websites you used the password manager with since
there is no database. I just don't see how I could ever want this. Or is it
assumed that master keys never need to be changed?

~~~
stepstep
It's true that changing the master key is a pain, but you don't have to do it
for every website at once. Though it might be hard during the transition to
remember which sites have the updated key.

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.

------
MiWDesktopHack
Use slower / heavier hash -- PBKDF2 or better. For lulz use something like
Darkcoin Cryptocurrency 'X11' Proof of Work function - multiple rounds of 11
different hashes. Or more. (X13, X15 and X17 all exist as PoW functions in
CryptoCurrencies today).

A <$1000 bitcoin (SHA-256) mining ASIC appliance is likely to be doing 1TH/s.
Makes 2^16 rounds look kinda weak.

------
dchest
Here's a short analysis of such password generators:
[http://crypto.stackexchange.com/a/5691/291](http://crypto.stackexchange.com/a/5691/291)

------
moe
This is why beginners should not design crypto, much less encourage others to
use their creations...

Do not use this, it's a textbook example of how to _not_ do it.

~~~
stepstep
Stanford published a paper that is basically the exact same model:
[http://crypto.stanford.edu/PwdHash/pwdhash.pdf](http://crypto.stanford.edu/PwdHash/pwdhash.pdf)

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.

~~~
moe
_Stanford published a paper that is basically the exact same model_

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.

[1]
[https://www.achilleslabs.com/product/4](https://www.achilleslabs.com/product/4)

~~~
stepstep
2^16 rounds of SHA-256 might not be "ultra slow" but it's certainly not as bad
as you make it seem. If you read the analysis in the article, it would take
many years to crack a random password with this hash function. It's unfair to
say I "ignored" that requirement.

~~~
moe
_If you read the analysis in the article, it would take many years to crack a
random password with this hash function._

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.

------
hrvbr
[http://passwordmaker.org](http://passwordmaker.org) does the same thing and
already has extensions for all browsers.

------
rnbrady
This is awesome. Minimal and elegant.

------
dsego
Similar [https://getvau.lt](https://getvau.lt)

