PwdHash (2009)

This was one of the first &quot;deterministic password managers&quot;, which has become a whole species of side-project password managers. The major practical win for deterministic password managers is that they&#x27;re ostensibly stateless; you only need to synchronize some very basic configuration information to make them work consistently. In practice, not so much: passwords need to be changed, or revoked, or customized. You should just use &quot;pass&quot; (or 1Password if you want something professional).<p>An interesting thing about PwdHash is that they observed how you can use site-specific authentication behavior to break phishing, something that U2F&#x2F;Webauthn tokens also accomplish.

This should just be how websites work. I see no reason that a site should ever transmit the user&#x27;s password over the wire.<p>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&#x2F;hash it again.<p>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.<p>^ inb4 &quot;this creates another &#x27;step&#x27; when logging in.&quot; Users will type their username and pw before they get the salt and the client will handle the rest.

Used this extensively before password managers were abundant—even wrote my own bookmarklet for it ~10 years ago[0]. One thing to be mindful of: login URLs can and do change. When this happens, unless you can recall the hostname, you&#x27;re completely out of luck.<p>[0]: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;jasisk&#x2F;fc0283e84814c696d3cd" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;jasisk&#x2F;fc0283e84814c696d3cd</a>

What a coincidence as I&#x27;m reading up on deterministic password generators:<p>- DPG: <a href="https:&#x2F;&#x2F;plevyak.com&#x2F;dpg.html" rel="nofollow">https:&#x2F;&#x2F;plevyak.com&#x2F;dpg.html</a><p>- MasterPassword: <a href="https:&#x2F;&#x2F;masterpassword.app&#x2F;" rel="nofollow">https:&#x2F;&#x2F;masterpassword.app&#x2F;</a><p>- LessPass: <a href="https:&#x2F;&#x2F;lesspass.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lesspass.com&#x2F;</a><p>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&#x27;t need to enter my master password as often.<p>One idea I&#x27;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:<p>1.this db would store states for the calculator that user would need to manually re-enter, and it&#x27;s URL would be only known to user (say a Google sheets, json URL)<p>2. This URL would be stored for limited time on browser cache improving UX for short period of time.<p>3. The db itself won&#x27;t store secrets, just &quot;metadata&quot;

SuperGenPass[1] is a refinement of this idea. The code itself has been dormant for years[2], but the bookmarklet and mobile web versions still work great. In fact, adding the mobile web page to my iPhone home screen with Safari makes this a pretty straightforward way to make passwords accessible on mobile without worrying about syncing.<p>1: <a href="https:&#x2F;&#x2F;chriszarate.github.io&#x2F;supergenpass&#x2F;" rel="nofollow">https:&#x2F;&#x2F;chriszarate.github.io&#x2F;supergenpass&#x2F;</a> 2: Since 2016 :( <a href="https:&#x2F;&#x2F;github.com&#x2F;chriszarate&#x2F;supergenpass&#x2F;commits&#x2F;master" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;chriszarate&#x2F;supergenpass&#x2F;commits&#x2F;master</a>

This is definitely pre-2009, I built this at Stanford w&#x2F; the others and I was only at Stanford until around 2005. (But they may have continued updating it given the Firefox version number referenced.)

I haven&#x27;t yet decided how I feel about this vs a full password manager (with unique passwords per site), but do kind of like the idea there&#x27;s no account&#x2F;vault: literally the entire usage is via a single password.<p>I have a suggestion to greatly increase usability:<p>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).<p>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&#x27;t need to re-enter it.<p>Interesting idea&#x2F;project nonetheless.<p>Edit: oops, just noticed this is from 2009. I noticed lack of Chrome but not the ancient browser versions! Did this go anywhere?

This reminds me of PasswordMaker[1], a neat tool that you can easily self host (or run offline from your filesystem) and customize. The basic idea is that you don&#x27;t have to store any passwords, but you can still easily have a different one for every account. You generate a hash based on the domain&#x2F;hostname and the master password.<p>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.<p>[1]: <a href="https:&#x2F;&#x2F;passwordmaker.org&#x2F;passwordmaker.html" rel="nofollow">https:&#x2F;&#x2F;passwordmaker.org&#x2F;passwordmaker.html</a>

This is equivalent to hashing passwords using a global public salt (the domain name). If it became popular enough, you could mount a trivial offline dictionary attack on popular passwords.

This creates longer password even with a short master pass: <a href="https:&#x2F;&#x2F;ss64.com&#x2F;pass&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ss64.com&#x2F;pass&#x2F;</a>

<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Salt_(cryptography)" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Salt_(cryptography)</a> (1970)

This would break if the site owner changed their domain name, or more likely, they have multiple domains that redirect to the same IP address. Is that a serious flaw?

Needs year in the title: (2009)