8 ms·

We've seen many of these tools and they are all flawed in the same way. - Setting the master password to something insecure will undermine the security of all

by Dinux 7y ago

We've seen many of these tools and they are all flawed in the same way. - Setting the master password to something insecure will undermine the security of all derived passwords. The same thing can be said for traditional password managers but they at least do not correlate the master password to all other service passwords. - Master key is related to the generated passwords. Using a strong PBKDF this should not be a problem, but why take the risk? - Leaked passwords cannot be changed. - There are enough services which generate you a password and then only later lets you change it. - Cannot store PIN, ID, CVV, files etc.

anfilt 7y ago
If you choose a strong master key this should still be secure even if a site leaks a generated sub-key/password. All you need to do is change the sub-key for that site. Both this and password managers though still can be hosed if the machine your using is compromised. Otherwise it should be secure as your master key. Leaked passwords can be changed for this they have what looks like a version input. If the master key can be reversed from a cryptographic hash function either the hash function has been broken or you chose a really bad master key. Although storing PINs and all the other random things some sites may use is a valid point. I am not sure I would call this less secure than a traditional password manager though.
zimbatm 7y ago
- LessPass is a webpage that can be changed at any time and collect website, username and password triplets. This is quite a big issue because it can be used for targeted attacks. There is no way of detecting compromises without reading the source on every page load.
- op00to 7y ago
  There is no way you can tell if there’s an undetectable worm in your system.
  - baobabKoodaa 7y ago
    Those things are in no way comparable. First of all, this is not a transfer of trust from A to B: in both cases (traditional password manager or this thing) you still need to trust that your own device is not compromised. But with this thing, you _also_ need to trust that the website is not compromised. Secondly, the website is a much juicier attack target than your personal computer.
- sarakayakomzin 7y ago
  I dont understand why you would let a malicious actor access this in the first place.
- bad_user 7y ago
  In all fairness, it's trivial to host it yourself.
ravenstine 7y ago
> - Leaked passwords cannot be changed. What's funny is I nearly just finished making a Node.js library that does what Lesspass does, and it addresses this one point. Basically, I added a concept of an `nonce` property, which is just a number that gets incremented every time a password for a service has to change. (not sure if nonce is the correct term) I figure that if I forget a password, I can just keep adding 1 to the nonce until it generates the current password. Here's a gist of it: https://gist.github.com/Ravenstine/8053651dd2aeacee9973b9f93a892311 https://gist.github.com/Ravenstine/8053651dd2aeacee9973b9f93... I haven't used it anywhere, so if there's a serious flaw don't believe you're going to access my bank account. lol EDIT: It looks like Lesspass also uses a counter property. Kinda amazed that two people independently arrived at such a similar idea. :)
- gruez 7y ago
  >Basically, I added a concept of an `nonce` property, which is just a number that gets incremented every time a password for a service has to change. So your solution to issues with stateless password managers is to... add state?
  - ravenstine 7y ago
    In a sense, but not state that gets stored anywhere. The "state" that's being mentioned in this thread is referring to storing state in some kind of database. My idea was to not require storage of state outside of the human mind, and to make any state easily guessable(by the owner) through exhaustive search. Even Lesspass uses an incremented number for that purpose, from what I can tell. So it adds state in the sense that you're talking about.
- dspillett 7y ago
  I had a similar intent for less important accounts (I would keep using a more secure but less convenient solution for more significant credentials). To shortcut guessing the index you could store just the site plus index in a cookie or similar - if that data is lost you can still use the guesswork option. If tracking is a concern so you don't want site names to be stored, has the site name and index and use that to build a bloom filter (not perfect, but it will usually guess right without storing the actual data). Though for my use I wouldn't care that the site names were known. Another similar idea to stop people using the "just add a character or increment a number" method for dealing with passwords that need to be changed monthly. The password is based upon a hash of master+site+year+month+salt. You are still compromised if the master password is compromised, it is never any worse than what people do already. Again I'd not use this sort of thing for truly important accounts. > Kinda amazed that two people independently arrived at such a similar idea. :) I've seen many similar schemes, some identical to those I've considered and either dismissed of not found time to think through, some with minor variations. I think this is a problem a lot of people encounter so it is a common though-game, so I'm not surprised that for every combination of tricks there are a number of people who have thought the same (or even got around to implementing something).
fluidcruft 7y ago
Also it requires you to remember usernames or email addresses used at each website. For the last 8+ years I've been using unique usernames and emails at each website. I also have to deal with a number of systems that require me to change passwords every 3 months and I don't want to also be remembering dates. I can't remember what the crisis was but it was after Ashley Madison and there had been a series of password databases put up on tor. And also there were some things about people getting harassed across platforms. It happened right before I moved to a new state and when I set up all my new utilities and banking and etc I used a password manager and created unique username flavors. Like fluidcruft253b for water and fluidcruftAdaG for gas and fluidcruft563d for banking etc.
- ravenstine 7y ago
  > Also it requires you to remember usernames or email addresses used at each website. For the last 8+ years I've been using unique usernames and emails at each website. I also have to deal with a number of systems that require me to change passwords every 3 months and I don't want to also be remembering dates. Interesting idea, but that seems like overkill to me. Like, yeah, if I was to sign up for Ashley Madison, it would be ideal for me to use an email that is not my known one. ;) But in most cases I don't think that's adding much extra security. If anything, you're more likely to lose access to a site by forgetting what your super secret email for it was than from someone hacking it. This isn't to say that I'm totally against it. Part of me just feels like there's more that can go wrong doing it that way.
  - developer2 7y ago
    Those of us using a different random username and/or email address for each sender do it for two reasons: 1. If whichever identifier is used for login (eg. email address) is exposed/leaked, it cannot be used by the attacker to lookup accounts in other leak dumps. 2. It allows to detect which site/service/entity is selling or leaking email addresses to third parties which send spam. I no longer need or have a spam folder. The moment I receive a spam email from someone I don't recognize, I can lookup which site/service that email was for, and choose how to act; eg. update that site/service's to use a new email address and blackhole the old one; maybe unsubscribe/close the offending account if it happens again. Of course since setting up my unique-email-per-site setup, I haven't been victim to third-party spam yet; likely because I no longer have a personal email in public Github commits.
lewiscollard 7y ago
You make some reasonable points, but two I find somewhat strange: > Setting the master password to something insecure will undermine the security of all derived passwords Then don't do that. The question is: Is LessPass in practice more likely to encourage this kind of poor security than its alternatives? > Master key is related to the generated passwords. Using a strong PBKDF this should not be a problem, but why take the risk? If its PBKDF is broken then so is its security. If crypto is incorrectly implemented in any other password manager then it too is broken. If the crypto algorithms used by TLS are broken then our online banking is broken. We don't avoid other things that rely on crypto just in case they might get broken some day. [Mods: accidentally posted this as a top-level reply rather than a reply to this comment, sorry!]
diablo1 7y ago
https://tonyarcieri.com/4-fatal-flaws-in-deterministic-password-managers https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...

by Dinux 7y ago

anfilt 7y ago

If you choose a strong master key this should still be secure even if a site leaks a generated sub-key/password. All you need to do is change the sub-key for that site. Both this and password managers though still can be hosed if the machine your using is compromised. Otherwise it should be secure as your master key. Leaked passwords can be changed for this they have what looks like a version input. If the master key can be reversed from a cryptographic hash function either the hash function has been broken or you chose a really bad master key. Although storing PINs and all the other random things some sites may use is a valid point. I am not sure I would call this less secure than a traditional password manager though.

zimbatm 7y ago

- LessPass is a webpage that can be changed at any time and collect website, username and password triplets. This is quite a big issue because it can be used for targeted attacks. There is no way of detecting compromises without reading the source on every page load.

op00to 7y ago
There is no way you can tell if there’s an undetectable worm in your system.
- baobabKoodaa 7y ago
  Those things are in no way comparable. First of all, this is not a transfer of trust from A to B: in both cases (traditional password manager or this thing) you still need to trust that your own device is not compromised. But with this thing, you _also_ need to trust that the website is not compromised. Secondly, the website is a much juicier attack target than your personal computer.
sarakayakomzin 7y ago
I dont understand why you would let a malicious actor access this in the first place.
bad_user 7y ago
In all fairness, it's trivial to host it yourself.

ravenstine 7y ago

> - Leaked passwords cannot be changed. What's funny is I nearly just finished making a Node.js library that does what Lesspass does, and it addresses this one point. Basically, I added a concept of an `nonce` property, which is just a number that gets incremented every time a password for a service has to change. (not sure if nonce is the correct term) I figure that if I forget a password, I can just keep adding 1 to the nonce until it generates the current password. Here's a gist of it: https://gist.github.com/Ravenstine/8053651dd2aeacee9973b9f93a892311 https://gist.github.com/Ravenstine/8053651dd2aeacee9973b9f93... I haven't used it anywhere, so if there's a serious flaw don't believe you're going to access my bank account. lol EDIT: It looks like Lesspass also uses a counter property. Kinda amazed that two people independently arrived at such a similar idea. :)

gruez 7y ago
>Basically, I added a concept of an `nonce` property, which is just a number that gets incremented every time a password for a service has to change. So your solution to issues with stateless password managers is to... add state?
- ravenstine 7y ago
  In a sense, but not state that gets stored anywhere. The "state" that's being mentioned in this thread is referring to storing state in some kind of database. My idea was to not require storage of state outside of the human mind, and to make any state easily guessable(by the owner) through exhaustive search. Even Lesspass uses an incremented number for that purpose, from what I can tell. So it adds state in the sense that you're talking about.
dspillett 7y ago
I had a similar intent for less important accounts (I would keep using a more secure but less convenient solution for more significant credentials). To shortcut guessing the index you could store just the site plus index in a cookie or similar - if that data is lost you can still use the guesswork option. If tracking is a concern so you don't want site names to be stored, has the site name and index and use that to build a bloom filter (not perfect, but it will usually guess right without storing the actual data). Though for my use I wouldn't care that the site names were known. Another similar idea to stop people using the "just add a character or increment a number" method for dealing with passwords that need to be changed monthly. The password is based upon a hash of master+site+year+month+salt. You are still compromised if the master password is compromised, it is never any worse than what people do already. Again I'd not use this sort of thing for truly important accounts. > Kinda amazed that two people independently arrived at such a similar idea. :) I've seen many similar schemes, some identical to those I've considered and either dismissed of not found time to think through, some with minor variations. I think this is a problem a lot of people encounter so it is a common though-game, so I'm not surprised that for every combination of tricks there are a number of people who have thought the same (or even got around to implementing something).

fluidcruft 7y ago

Also it requires you to remember usernames or email addresses used at each website. For the last 8+ years I've been using unique usernames and emails at each website. I also have to deal with a number of systems that require me to change passwords every 3 months and I don't want to also be remembering dates. I can't remember what the crisis was but it was after Ashley Madison and there had been a series of password databases put up on tor. And also there were some things about people getting harassed across platforms. It happened right before I moved to a new state and when I set up all my new utilities and banking and etc I used a password manager and created unique username flavors. Like fluidcruft253b for water and fluidcruftAdaG for gas and fluidcruft563d for banking etc.

ravenstine 7y ago
> Also it requires you to remember usernames or email addresses used at each website. For the last 8+ years I've been using unique usernames and emails at each website. I also have to deal with a number of systems that require me to change passwords every 3 months and I don't want to also be remembering dates. Interesting idea, but that seems like overkill to me. Like, yeah, if I was to sign up for Ashley Madison, it would be ideal for me to use an email that is not my known one. ;) But in most cases I don't think that's adding much extra security. If anything, you're more likely to lose access to a site by forgetting what your super secret email for it was than from someone hacking it. This isn't to say that I'm totally against it. Part of me just feels like there's more that can go wrong doing it that way.
- developer2 7y ago
  Those of us using a different random username and/or email address for each sender do it for two reasons: 1. If whichever identifier is used for login (eg. email address) is exposed/leaked, it cannot be used by the attacker to lookup accounts in other leak dumps. 2. It allows to detect which site/service/entity is selling or leaking email addresses to third parties which send spam. I no longer need or have a spam folder. The moment I receive a spam email from someone I don't recognize, I can lookup which site/service that email was for, and choose how to act; eg. update that site/service's to use a new email address and blackhole the old one; maybe unsubscribe/close the offending account if it happens again. Of course since setting up my unique-email-per-site setup, I haven't been victim to third-party spam yet; likely because I no longer have a personal email in public Github commits.

lewiscollard 7y ago

You make some reasonable points, but two I find somewhat strange: > Setting the master password to something insecure will undermine the security of all derived passwords Then don't do that. The question is: Is LessPass in practice more likely to encourage this kind of poor security than its alternatives? > Master key is related to the generated passwords. Using a strong PBKDF this should not be a problem, but why take the risk? If its PBKDF is broken then so is its security. If crypto is incorrectly implemented in any other password manager then it too is broken. If the crypto algorithms used by TLS are broken then our online banking is broken. We don't avoid other things that rely on crypto just in case they might get broken some day. [Mods: accidentally posted this as a top-level reply rather than a reply to this comment, sorry!]

diablo1 7y ago

https://tonyarcieri.com/4-fatal-flaws-in-deterministic-password-managers https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...