PwdHash (2009)
crypto.stanford.edu
crypto.stanford.edu
An interesting thing about PwdHash is that they observed how you can use site-specific authentication behavior to break phishing, something that U2F/Webauthn tokens also accomplish.
Imagine you're signing into https://fake-google.example/ having been tricked into believing it is Google but with various different types of credentials:
* With a memorised password or similar strategy, you give them your actual Google credentials. Game over, you lose.
* With password managers you might realise there is something wrong because it doesn't auto-complete. But you might (for various reasons) give them your Google credentials, after all you've been tricked into believing this is Google. Game over, you lose.
* With PwdHash you give them PwdHash(Google Credentials). Reversing that to find your Google Credentials depends on your entropy choices. For good passwords you win, but most user passwords mean you lose if the bad guys put work in.
* With most "Second Factor" designs including SMS, TOTP, and many dongle designs you give them the second factor and again, you lose if the bad guys planned for this.
* But with WebAuthn its "cookies" (which bad guys can get from the real Google by presenting your username) are themselves site specific. Your FIDO authenticator needs a cookie, and it will implicitly need the cookie to match the rpId, your browser insists the rpId must match the origin FQDN of the web site (fake-google.example in this case) but that won't match google.com so the authentication cannot succeed. You cannot give the bad guys your Google credentials even if you really want to, maybe short of sending them the actual authenticator itself.
[ Do not UPS your Security Keys to bad guys. I think even my deceased grandmother could have figured that out, if I read stories about people being successfully tricked into doing this I may despair about our species entirely ]
You can't think in terms of "does happen" and "doesn't happen," you have to think in terms of "90% chance," "10% chance," "1% chance..." and so on. So many times I have seen people reject good measures by giving an argument to the effect of "Your system has a 1% chance of failure, which in my brain is stored as 'can fail,' so it's not an improvement over the old system that fails 30% of the time, which is also stored in my brain as 'can fail.'"
You'd be surprised. Back in the day banks here used what amounts to a one-time pad as a second factor for auth. You'd wire money and the bank would ask you for code #37 on your one time pad. Each code would only ever be used once and if your codes were near to running out your bank would send you a new one time pad.
A pretty clever and secure system you'd think. This of course didn't stop scammers from sending letters to people pretending to be their bank, asking if they could send in their old one-time pad and pin code in exchange for a new one time pad. Enough people fell for this for it to be an actual problem.
It's not quite sending your security keys to the bad guys but it gets pretty close!
When you create a password send the client a salt, hash their real password client side, and send the hash over the wire. Treat it as you would their actual password and salt/hash it again.
Then when the user wants to auth send the client the salt you have on file for them^ and repeat. Bam. A domain specific password for every site even for someone who who reuses passwords.
^ inb4 "this creates another 'step' when logging in." Users will type their username and pw before they get the salt and the client will handle the rest.
The attack you're protecting against is a compromise of the server's password database. If the attacker has that, then they have the client side salt too.
Hashing a second time on the server protects from a database leak being used to access the site.
No it doesn't, because all of those attackers have access to the client side salt which is sent to the client in the clear.
Now, depending on the hashing algorithm, maybe it's easy to turn that back into the plaintext, but with a competent hash, it's not expected to be easy.
Edit to add, if the site does it in javascript, of course they (or intermediaries) could decide not to do it, or to also pass the plaintext with the hashed version. That's a separate issue.
The dictionary attack on the client created hash and the attack on the server hash of the plaintext take the same effort.
This measure is to limit the blast radius of a compromised password given that people reuse passwords.
All you've done is move your attack from the server to the client. It's the same attack on both ends.
If the password is so weak that you can just invert the hash then there's not much that can help you.
In the first case, there's a 100% chance of the password being compromised, but in the second an attacker has to spend resources on cracking a password, and there's still a small chance that they're unable to crack it. The second case seems like a clear winner (I could still be missing something).
So sure, you may have prevented the release of a reused password, but you haven't prevented anyone from impersonating your user on your site.
Depending on how they have access to your plaintext conversation, they could get your reused password from another site.
In other words, while this might make a slight difference in the stealing of reused passwords, it's not really worth the effort. There are far better solutions, like encouraging the use of a password manager.
That is the whole point. In this system the hash generated on the client is literally your password. It's just to provide some extra protection for people who reuse passwords that are compromised on the server or over the wire.
>There are far better solutions, like encouraging the use of a password manager.
That might be better but your solution requires telling billions of people to not reuse passwords and use a password manager. Or you could implement this on your site and your users are instantly better off. Real users are better off if we just make their behavior safer.
That's not a realistic use case if you use https on your site.
The effort in implementing this, testing it, testing fallbacks when Javascript is unavailable, testing every change with the fallback on and off, and so on, just isn't worth it for that absolutely tiny gain.
Why would you send it in the clear?
Also I agree that it's not clear how is it useful, if your server password database is already hashed.
For example this Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=472823
Or we could use WebAuthn. I am very curious whether it will get any recognition and support. I am definitely rooting for it.
If the phishing site presents a ui that looks like the real site, the user could be tricked into entering his real username/password which the attacker could then use to log into the real site.
Or am I missing something?
- DPG: https://plevyak.com/dpg.html
- MasterPassword: https://masterpassword.app/
- LessPass: https://lesspass.com/
I like the idea of such mechanism for my passwords, but I feel like having to enter a masterpassword so often actually poses as a vunerability. The password managers I currently use, normally enables me to use fingerprint or leaves some minutes before timing out so that I don't need to enter my master password as often.
One idea I'm having is to combine the deterministic and stateless aspect of a simple js generator, with a simple db that user can maintain with a online spreadsheet:
1.this db would store states for the calculator that user would need to manually re-enter, and it's URL would be only known to user (say a Google sheets, json URL)
2. This URL would be stored for limited time on browser cache improving UX for short period of time.
3. The db itself won't store secrets, just "metadata"
https://passwordmaker.org/passwordmaker.html
On Chrome the extension you want is PasswordMaker Pro (not paid, it's just a name). It allows you to save profiles for different domains and saves them wherever it is Chrome extensions save data.
1: https://chriszarate.github.io/supergenpass/ 2: Since 2016 :( https://github.com/chriszarate/supergenpass/commits/master
I have a suggestion to greatly increase usability:
Right now, as the owner points out, this relies on using a password starting with @@ to trigger this mechanism (which is a usability issue), and relying on the user entering their passwords into the web page (which is a phishing danger).
Given this already requires a browser extension, move the password to a UI within the extension, and instruct the user not to ever enter their password anywhere else (on why page directly). Use a button in the browser extension to trigger filling in the site-specific password. This avoids phishing the main password, avoids the @@-prefix requirement, and the extension could now also cache the password for some amount of time so the user doesn't need to re-enter it.
Interesting idea/project nonetheless.
Edit: oops, just noticed this is from 2009. I noticed lack of Chrome but not the ancient browser versions! Did this go anywhere?
It worked really well for a long time, tho eventually I ran into enough corner cases that I had to switch to a traditional password manager anyway. I still use it for some stuff however.
To be fair that would also be a problem for many automated or semi-automated password managers. I have PassFF for example and it's currently suggesting the password it knows for news.ycombinator.com, I think it would guess that hacker-news.ycombinator.com should also suggest that, but if this site moved to https://hacker-news.example/ I'd need to make the connection in my head to retrieve the password.
One important thing compared to WebAuthn, which has this behaviour built into it, is that the site owner doesn't know you use PwdHash and so their testing won't discover this problem, indeed they might insist it isn't a problem at all because it isn't part of their mental model of password behaviour.
Whereas in WebAuthn it just doesn't work, so even fairly light acceptance testing would discover that the new site can't re-use old WebAuthn credentials and that's a problem.
That's the oldest it goes for this site.