ZeroVault: A password-hell life buoy from purgatory.

[Rob Meijer]

If disliking passwords was a sport I'dd be an Olympic contestant for sure, and as much as I'dd like to avoid password-hell all together, 

I do have my collection of way to many websites that require me to have a password for them.  If there is one thing I dislike almost as 

much as passwords it is the concept of password vaults.

To get myself from the insecure password hell of sometimes using unique passwords for whole classes of websites without having to resort 

to the other hell of password vaults, I wrote myself a tiny bit of python and javaScript in order to help me out that I think might be useful and 

an interesting use case for BLAKE2 for creating a directional tree of sparse capabilities, usernames and passwords.

https://github.com/pibara/ZeroVault

ZeroVault in no way fixes password hell, it does however make it a tiny bit more secure and more manageable I think.  

Any feedback or pull requests are very much welcomed.

Rob

[Alan Karp]

An interesting approach.  You should also check out Ka-ping Yee's PassPet, http://passpet.org/, and my SitePassword, https://sitepassword.alanhkarp.com/.  The latter is also available as a Chrome extension, but I have to add you to the list of testers before you can get it. 

One problem you'll run into is sites with funny password rules.  For example, some don't allow special characters, and others require one or more from a select set.  SitePassword was able to compute a valid password for all sites in the Alexa 150.  Another problem will be changing just one password.  SitePassword uses the site nickname for that.

One advantage you have is the initial passphrase, which makes your approach much more secure against guessing attacks.  I'll probably add that feature to SitePassword when I get a chance.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+unsubscribe@googlegroups.com.
To post to this group, send email to cap-...@googlegroups.com.
Visit this group at https://groups.google.com/group/cap-talk.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/098a4d4f-197a-4c0a-94b1-c09a1cc600a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tony Arcieri]

On Wed, Nov 16, 2016 at 12:53 AM, Rob Meijer <pib...@gmail.com> wrote:

To get myself from the insecure password hell of sometimes using unique passwords for whole classes of websites without having to resort 

to the other hell of password vaults, I wrote myself a tiny bit of python and javaScript in order to help me out that I think might be useful and 

an interesting use case for BLAKE2 for creating a directional tree of sparse capabilities, usernames and passwords.

https://github.com/pibara/ZeroVault

This is probably the 10th deterministic password generator I've seen someone announce this year. 

They have three fatal flaws:

1) If the generated password doesn't conform to the site's password policy, you have to "tweak" the generated password to comply

2) If a password is ever exposed (e.g. accidentally pasted into IRC/Slack/Twitter or what have you) you need at least some sort of per-site counter you can bump to get a new password

3) You can't change your master password without changing every other password

Solving these problems requires a stateful password manager, at which point you might as well use random, conforming passwords for each site.

--

Tony Arcieri

[Dan Connolly]

On Wed, Nov 16, 2016 at 11:02 AM, Tony Arcieri <bas...@gmail.com> wrote:
[...]
>> https://github.com/pibara/ZeroVault

Looks analagous to supergenpass, which has been around in various
forms at least as far back as 2014.
https://chriszarate.github.io/supergenpass/

It is also available as browser extensions (for chrome and firefox at
least) and a fairly nice android app that integrates with the 'share'
hook.

I re-implemented it in <100 lines of python (including tests) to make
sure I understood the algorithm.
https://gist.github.com/dckc/1335610


--
Dan Connolly
http://www.madmode.com/

[Tony Arcieri]

On Wed, Nov 16, 2016 at 10:58 AM, Dan Connolly <dc...@madmode.com> wrote:

Looks analagous to supergenpass, which has been around in various
forms at least as far back as 2014.

Stanford PwdHash dates back to 2005:

https://www.pwdhash.com/

 

--

Tony Arcieri

[Alan Karp]

PwdHash has two problems. There’s no way to deal with funky password rules. More importantly, it uses the domain name in the hash, so there’s no way to change just one password.

________
Alan Karp

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To post to this group, send email to cap-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/cap-talk.

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHOTMVK_u3PEz7trMJPqrgod52vH9wen-n%3D4CMPu%2Be6McuKBSQ%40mail.gmail.com.

[Tony Arcieri]

On Wed, Nov 16, 2016 at 11:09 AM, Alan Karp <alan...@gmail.com> wrote:

PwdHash has two problems.  There’s no way to deal with funky password rules.  More importantly, it uses the domain name in the hash, so there’s no way to change just one password.

There's no way to solve either of these problems with deterministic password managers without keeping state. And if you're keeping state, what's the point of a deterministic password manager?

--

Tony Arcieri

[Rob Meijer]

For the second one, it might be sufficient to only keep (by lack of a better word) 'negative' state. That is, only keep just enough state to test for revocation, then add an other HMAC or BLAKE2 round until a non revoked password is found. 

[Alan Karp]

> Tony Arcieri <bas...@gmail.com> wrote:

> There's no way to solve either of these problems with deterministic password managers without keeping state. And if you're keeping state, what's the point of a deterministic password manager?

SitePassword only keeps state of minor security value, basically your userID, nickname for the site, and parameters needed for the password rules. I was working on a version that synchronized this state across machines until Facebook decided to kill Parse. Meanwhile, I keep this information on my web site in case I need to log in from a new machine.

________
Alan Karp

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
> To post to this group, send email to cap-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/cap-talk.

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHOTMVLOPXhCnw3LP6heOSgwZcnyD4PmaRBThc-WgC0pZyc-Og%40mail.gmail.com.

[Tony Arcieri]

On Wed, Nov 16, 2016 at 1:43 PM, Alan Karp <alan...@gmail.com> wrote:

SitePassword only keeps state of minor security value, basically your userID, nickname for the site, and parameters needed for the password rules. I was working on a version that synchronized this state across machines until Facebook decided to kill Parse.  Meanwhile, I keep this information on my web site in case I need to log in from a new machine.

I would argue ciphertext is "state of minor security value", provided it's encrypted correctly.

--

Tony Arcieri

[Alan Karp]

My site info is not encrypted. I’m assuming that a bad guy can guess my userID and nickname for a given site. What I’m hoping the bad guy can’t guess is my master password.

________
Alan Karp

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
> To post to this group, send email to cap-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/cap-talk.

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHOTMV%2Bf8q%3DdFm9Tz9GE2MdvooDwb_0xrhZVLL6tBFWVQex1Vg%40mail.gmail.com.

[Tony Arcieri]

On Wed, Nov 16, 2016 at 1:52 PM, Alan Karp <alan...@gmail.com> wrote:

My site info is not encrypted.  I’m assuming that a bad guy can guess my userID and nickname for a given site.  What I’m hoping the bad guy can’t guess is my master password.

I'm saying the threat is equivalent to the encrypted state of most password managers (an attacker has to be able to guess your password for it to be useful), so why not just use an encrypted vault?

The benefit of an encrypted password vault is you can store much richer information about a particular site. Many sites have more than one password, might have security questions, those security questions might be multiple choice so if you want to get around the stupidity of security questions you have to pick random answers, etc e.g. https://twitter.com/bcrypt/status/698265259962822656

A stateful deterministic password manager cuts you out of this sort of utility. You also can't use it to store things like encryption keys which aren't similarly derived deterministically from a password.

And the coup de grace: you can't easily change your master password.

--

Tony Arcieri

[Alan Karp]

> Tony Arcieri <bas...@gmail.com> wrote:

> I'm saying the threat is equivalent to the encrypted state of most password managers (an attacker has to be able to guess your password for it to be useful), so why not just use an encrypted vault?
>
> The benefit of an encrypted password vault is you can store much richer information about a particular site. Many sites have more than one password, might have security questions, those security questions might be multiple choice so if you want to get around the stupidity of security questions you have to pick random answers, etc e.g. https://twitter.com/bcrypt/status/698265259962822656
>
> A stateful deterministic password manager cuts you out of this sort of utility. You also can't use it to store things like encryption keys which aren't similarly derived deterministically from a password.
>
> And the coup de grace: you can't easily change your master password.

All true, but there’s an offline attack if the bad guy gets your encrypted file, which happened when LastPass got hacked. You’d have to use your stateful deterministic password manager to log into the bad guy’s site before facing the same risk. Besides, there’s nothing to say that you can’t use one master password for high value sites, such as banking, and another one for low value sites, such as newspaper subscriptions.

________
Alan Karp

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
> To post to this group, send email to cap-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/cap-talk.

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHOTMVLqCmo3snQvd5i7K7CQCVUd_rKz-Z4dyQX6yuvw05vmsA%40mail.gmail.com.

[Rob Meijer]

2016-11-16 23:08 GMT+01:00 Alan Karp <alan...@gmail.com>:

> Tony Arcieri <bas...@gmail.com> wrote:

> I'm saying the threat is equivalent to the encrypted state of most password managers (an attacker has to be able to guess your password for it to be useful), so why not just use an encrypted vault?
>
> The benefit of an encrypted password vault is you can store much richer information about a particular site. Many sites have more than one password, might have security questions, those security questions might be multiple choice so if you want to get around the stupidity of security questions you have to pick random answers, etc e.g. https://twitter.com/bcrypt/status/698265259962822656
>
> A stateful deterministic password manager cuts you out of this sort of utility. You also can't use it to store things like encryption keys which aren't similarly derived deterministically from a password.
>
> And the coup de grace: you can't easily change your master password.

All true, but there’s an offline attack if the bad guy gets your encrypted file, which happened when LastPass got hacked.  You’d have to use your stateful deterministic password manager to log into the bad guy’s site before facing the same risk.  Besides, there’s nothing to say that you can’t use one master password for high value sites, such as banking, and another one for low value sites, such as newspaper subscriptions.

​I currently use five passphases myself with ZeroVault:

1) Master passphrase

2) Vendor neutral money access generator passphrase

3) Vendor specific money access generator passphrase

4) Full identity access generator access

5) Other​

 

​generator access

​With respect to maintaining state, I think the only per master root cap state that should really be needed would be revocation info. If a workstation is compromised then all generator passwords used after comprimisation are compromised and all underlying site passwords should ba changed anyway so state would have of little use there. If a single generated password is compromised then the only state needed would be a revocation state token. Consider the following:

MC = blake2(masterpf,serversalt)

​rounds = 0:

RK = MC

do:

     rounds++

     RK = blake2(account,blake2(domain,RK))

while (server->isRevoked(MC,RK));

PK = blake2(generatorpf,MC)

for 1 .. rounds:

      PK = blake2(account,blake2(domain,RK))

pass = pk2pass(PK,repository->getsitepwtweaks(domain))

[Rob Meijer]

​That would be:

           ​ PK = blake2(account,blake2(domain,PK))

 

pass = pk2pass(PK,repository->getsitepwtweaks(domain))

[Rob Meijer]

On Wednesday, 16 November 2016 18:02:25 UTC+1, Tony Arcieri wrote:

On Wed, Nov 16, 2016 at 12:53 AM, Rob Meijer <pib...@gmail.com> wrote:

To get myself from the insecure password hell of sometimes using unique passwords for whole classes of websites without having to resort 

to the other hell of password vaults, I wrote myself a tiny bit of python and javaScript in order to help me out that I think might be useful and 

an interesting use case for BLAKE2 for creating a directional tree of sparse capabilities, usernames and passwords.

https://github.com/pibara/ZeroVault

This is probably the 10th deterministic password generator I've seen someone announce this year. 

They have three fatal flaws:

1) If the generated password doesn't conform to the site's password policy, you have to "tweak" the generated password to comply

Good point, I've only ran into a max-size one so far, but I guess there are others that wouldn't allow my 32 character default. Added a place to maintain such info now: https://github.com/pibara/ZeroVault/blob/master/templates/mapping.json

 

2) If a password is ever exposed (e.g. accidentally pasted into IRC/Slack/Twitter or what have you) you need at least some sort of per-site counter you can bump to get a new password

Think I've found a simple solution for that, using a blake2/hmac based tree structure again so zero security sensitive data is ever centrally stored in a reversible way.

Give the revocation button a try and let me know what you think. I may need to add some DOS protection still, but I think this should be a good way to do such a thing.

https://password.capibara.com/

 

3) You can't change your master password without changing every other password

If you have reason now to change the master password, you would probably need to do that anyway. So with revocation in place I don't think the need would arise to actualy revoke the master key without needing to revoke all passwords anyway.