1. 15
  1. 5

    What do people do with these when a website becomes compromised and they need ot change their password?

    1. 1

      they can use a suffix or prefix in the site name, eg;, twitter.com, twitter.com:1, twitter.com:2 …

      1. 14

        Sounds like state, to me!

        1. 2

          oneshallpass is the best implemention of this idea I’ve seen, so far. Yes, there’s state involved, but that state keeps track of options, and requirements for the site, only.

          I think there’s an opportunity for the password requirements part to be put in a block chain of sorts and shared publicly. Then, the only state you’d need to store would be the generation, and the strength params of your generated password. It’d be pretty easy to encrypt this state with a key derived from the master password and add it to Dropbox so it’s readily available.

          Of course, that leaves master password rotation, which, if you want something that supports that, you’re best bet is probably to use the master password to encrypt your state file, which has some strong pregenerated entropy that is actually used for your generating your passwords.

          The state file has the potential to leak sites you have accounts on (since you need to store the generation with an identifier of some sort), but it’s unlikely to matter as you only need to store the generation after a site has been compromised (public information, usually), and if they get access to your encrypted state file, they’d have access to entropy your passwords are based on, or in the case that you don’t require master password rotation, the password that derived the key to open the prefs file (e.g. your master password).

          So, stateless as a goal seems great, but totally impractical, from my perspective.

          1. 1

            How much would be lost in maintaining an unencrypted, publicely available, file that mapes twitter.com -> twitter.com:1 or similar? So the “name” you’ve given a website is publicly available people probably already know (or have a good idea) you’re using the domain name previously anyways, so perhaps not much is lost?

            To me, all of this seems very similar to why I’m iffy on biometrics. I cannot change my fingerprints either so what happens when that technology gets compromised in some way? What are your thoughts on that?

            1. 1

              As with many systems involving keys, the more secret the keys, the better. If I know one input to the alogrithm, thats one less barrier to figuring out the password for the site. It’d still be very difficult, mind you.

              This is different, imho, than biometrics, simply because twitter.com:1 is a convention. So long as the hash functions are not broken, and remain impossible to reverse at a cost that is worth the trouble, you can just evolve the twitter.com:1 to twitter.com:[32bit random] whenever twitter gets hacked, or you want to rotate your password. And, ultimately you have a failsafe–reset your passwords by changing your master key, or move on to a system with a different algorithm.

              edit forgot that angle brackets dont display.

    2. -5

      Slightly off topic, I’m not super interested in genpass (sorry), but I really like the layout of your blog.