Live data from Hacker News

Why traditional password managers are flawed

github.com

21–30 of 64 posts

Re: Why traditional password managers are flawed

#22
I don't think stateless is the answer, but I think that approaches like SPHINX is: http://webee.technion.ac.il/~hugo/sphinx.pdf

It deterministically generates passwords, and coupled with a statefull client you should be able to have a practical password manager that doesn't need to trust any third party.

Re: Why traditional password managers are flawed

#23

Despite the inflammatory title, these kinds of password "managers" that are stateless and rely instead on a hash system come up quite frequently but they never have an answer for some basic problems that plague real-life accounts and passwords. * Requirements of character sets used on different services. One upper case, two special characters, and 18 octothorps required. * Differing rotation schedules. ___ Bank force…

I use a system that I wrote https://github.com/kybernetikos/sinkless (incidentally it uses a similar system to this article - PBKDF with SHA512 - in browser plugins) that supports many of these situations. * The character sets can be entered manually. They form public information and are stored locally, can easily be exported as csv. * Each password has a 'version' which you can increment. The version is considered p…

> Also, even if it were true, storing the actual passwords means that you have a single point of failure - if the password storage is compromised the whole thing is compromised.

How is your system different? If I get ahold of your master key, your entire thing is compromised.

Re: Why traditional password managers are flawed

#24
post #23

Earlier quoted context omitted.

I use a system that I wrote https://github.com/kybernetikos/sinkless (incidentally it uses a similar system to this article - PBKDF with SHA512 - in browser plugins) that supports many of these situations. * The character sets can be entered manually. They form public information and are stored locally, can easily be exported as csv. * Each password has a 'version' which you can increment. The version is considered p…

> Also, even if it were true, storing the actual passwords means that you have a single point of failure - if the password storage is compromised the whole thing is compromised. How is your system different? If I get ahold of your master key, your entire thing is compromised.

This is true, but on the other hand the master key is never stored anywhere, so your chance of getting hold of it is reduced.

EDIT: as pointed out, no sensible system stores the master password. I do stand by the earlier 'single point of failure' point though. If you store a password vault somewhere and it goes down, or is encrypted by malware, or you lose the ability to access that storage for whatever reason you're stuck.

Re: Why traditional password managers are flawed

#25

Earlier quoted context omitted.

I use a system that I wrote https://github.com/kybernetikos/sinkless (incidentally it uses a similar system to this article - PBKDF with SHA512 - in browser plugins) that supports many of these situations. * The character sets can be entered manually. They form public information and are stored locally, can easily be exported as csv. * Each password has a 'version' which you can increment. The version is considered p…

If you store settings related to password system requirements on a per site basis then you're leaking the existence of your account on that site, which often needs to be private itself.

You're right. If you're worried about that, then you will need to treat that data as not entirely public. The point is just that the secrecy requirements can be much less than you'd have for keeping a password.

Re: Why traditional password managers are flawed

#26

Despite the inflammatory title, these kinds of password "managers" that are stateless and rely instead on a hash system come up quite frequently but they never have an answer for some basic problems that plague real-life accounts and passwords. * Requirements of character sets used on different services. One upper case, two special characters, and 18 octothorps required. * Differing rotation schedules. ___ Bank force…

Yeah, the random, terrible requirements of some sites is what will keep me on 1password. Yes, if I was specifically targeted I'm sure my accounts will be compromised, but the thing is I am not really concerned about that - the bigger problem is every random site losing user data every other week. If they have a throwaway password I am already better off than 95% of the population.

But honestly, it is quite unbelievable how many sites don't allow certain special characters, limit you to X characters, etc.

And I think one key factor that developers forget is convenience and UX, if a password manager is cumbersome, or only works on some sites, then the chances of a user dropping it will increase a ton.

Re: Why traditional password managers are flawed

#27

Despite the inflammatory title, these kinds of password "managers" that are stateless and rely instead on a hash system come up quite frequently but they never have an answer for some basic problems that plague real-life accounts and passwords. * Requirements of character sets used on different services. One upper case, two special characters, and 18 octothorps required. * Differing rotation schedules. ___ Bank force…

I agree with all these points completely, and I'd like to extend a bit more:

* The criticism of cloud-based storage isn't really valid. Any decent password manager should only sync the encrypted data, and never move anything unencrypted. * Browser integration isn't obligatory. Lots of PM's don't use that, and lots of users are okay with that, so that attack surface isn't an intrinsic part of a classic password manager.

Re: Why traditional password managers are flawed

#28

Despite the inflammatory title, these kinds of password "managers" that are stateless and rely instead on a hash system come up quite frequently but they never have an answer for some basic problems that plague real-life accounts and passwords. * Requirements of character sets used on different services. One upper case, two special characters, and 18 octothorps required. * Differing rotation schedules. ___ Bank force…

I use a system that I wrote https://github.com/kybernetikos/sinkless (incidentally it uses a similar system to this article - PBKDF with SHA512 - in browser plugins) that supports many of these situations. * The character sets can be entered manually. They form public information and are stored locally, can easily be exported as csv. * Each password has a 'version' which you can increment. The version is considered p…

An alphabet isn't enough to describe some [stupid] bank password requirements (I do admit the banks are really the problem here though).

Two banks I've worked with recently:

* No consecutive digits, not your initials. Numbers cant be your day, month or year of birth. * No repeating any symbol in the entire password. Cannot contain a subset of a previous key (I don't know how long the subset is to trigger this, but I do recall reusing 4 of 8 digits and seeing this).

Re: Why traditional password managers are flawed

#29
post #23

Earlier quoted context omitted.

> Also, even if it were true, storing the actual passwords means that you have a single point of failure - if the password storage is compromised the whole thing is compromised. How is your system different? If I get ahold of your master key, your entire thing is compromised.

This is true, but on the other hand the master key is never stored anywhere, so your chance of getting hold of it is reduced. EDIT: as pointed out, no sensible system stores the master password. I do stand by the earlier 'single point of failure' point though. If you store a password vault somewhere and it goes down, or is encrypted by malware, or you lose the ability to access that storage for whatever reason you're…

Isn't this true of 1Password and similar as well? My master key for 1Password isn't stored. That's what I need to enter to unlock my vault.

Re: Why traditional password managers are flawed

#30

    $ dpg "The sentence" word
Doesn't this store all your secret info in your .bash_history file, an unencrypted plain text file, with a convenient marker for finding it in the history file?

This is no better than just storing the password that DGP generates directly; it's deterministic and trivial to derive the password.

For somebody concerned about a "master password" being insecure, this is a far far worse solution.

Post reply on HN