Earlier quoted context omitted.
You are assuming that the site is not evil.
The site being evil is equivalent to the password being compromised.
And the password is the hash of the master password, which gives the evil all other passwords.
LessPass: sync-less open source password manager
241–247 of 247 posts
Re: LessPass: sync-less open source password manager
#242How do you deal with sites whose password requirements don't match the output of LessPass? How do you handle the fact that sites want you to change your password? Yes. There's a counter field, but how do you know what site uses what version of the counter? How do you change the master password without having to change all passwords? Thing is: There's a solution for all these problems: All you have to do is actually g…
> How do you deal with sites whose password requirements don't match the output of LessPass? How do you handle the fact that sites want you to change your password? Yes. There's a counter field, but how do you know what site uses what version of the counter? How do you change the master password without having to change all passwords?
While not perfect, I've addressed some of the issues in a similar password scheme of mine: https://github.com/onionjake/doh
* you can write specs for domains' specific password requirements so the generator can guarantee it is accepted * the counters you append to your password when generated are not sensitive so can be saved/synced * I have not addressed needing to change your master password, but I'd also like to point out using a password hashing scheme doesn't preclude you from having more than one master password, perhaps to segment work passwords from personal ones. * sometimes domains change as well, so you can log the domains used it generate passwords, which might be sensitive from a Metadata standpoint, but from a hack-your-password sorta way. This also helps when I use it for passwords other than websites (like ssh key passphrases)
> Thing is: There's a solution for all these problems: All you have to do is actually generating a random password and store
I agree that generating random passwords gives a better user experience, which it is much more popular. I prefer holding all of my data even if I could store it remotely encrypted so hashing was the clear choice. I also kept the algorithm simple so that I could implement it from memory on a strange computer if needed. Definitely not for everyone!
Re: LessPass: sync-less open source password manager
#243I have created Alzheimer Password Manager on the same ideas as this one.
I believe the better idea is to use also user specific salt per browser. In that case, the passwords are more unique, and the threat model changes dramatically.
Current Threat Model:
* No one with an access to the PC with installed extension should be able to authenticate without knowing the correct passphrase.
* The same passphrase used in two different web browsers should produce two different passwords (cryptographic salt will solve this problem).
* If an attacker obtains password for some websites, she should not be able to derive passwords for another websites using that knowledge.
* Attacker should not be able to brute force master passphrase from the salt and knowledge of one password (PBKDF with lots of iterations).
* it provides protection against basic keyloggers (but they can read our salt from the memory / file...)
https://chrome.google.com/webstore/detail/alzheimer-password...
Re: LessPass: sync-less open source password manager
#244Earlier quoted context omitted.
Okay, but now I have to remember 3x as many things as with a managed password manager. And how do I handle having multiple accounts on the same website? "You can put whatever you want in field X" is not a solution to the problem IMO.
> how do I handle having multiple accounts on the same website? You use the url of the site and your different logins to generate different passwords. What's so difficult about it. Anyway, I don't think there is a problem at all. Imagine this: I have 3 google accounts, which I use mainly for my gmail, another one for google play on my android and another one for my kids (google play, youtube). I could use the followi…
> You use the url of the site and your different logins to generate different passwords. What's so difficult about it.
Your suggested solution of "not using your actual login" requires me to remember something that is not related to my login. This means that for multiple different accounts I need to remember twice as many things. Which makes it impractical (they can't be linked to my account or else my profiles will reveal the information).
> Imagine this: I have 3 google accounts, ...
I have ~8 different gmail accounts, all of which are used for emails. Yes, they're for different purposes but your scheme won't help differentiate them without also giving away my logins.
Re: LessPass: sync-less open source password manager
#245What this seems to be, in essence: password = HMAC(key, website). Why this is bad, compared to an encrypted on-disk key store: 1. A password is now ciphertext, not a block of line noise. Every time you transmit it, you are giving away potential clues of use to an attacker. 2. The search space for possible passwords is bounded if you know the website. You are subject to key guessing attacks. If your key is short, pure…
Came here to point out the same concerns, basically. I'll add this: 5. Its seems like there is no user-specific secret in addition to the master password. If two users happen to use the same master password (which is definitely a possibility, especially with weak or easily memorizable passwords) they will basically have all the same passwords for every site! 6. Rotating your passwords regularly, at least for your hig…
>they will basically have all the same passwords for every site!
Not if the generated password also depends on your username.
Re: LessPass: sync-less open source password manager
#246I may be the inventor of in-browser hash-based password generation – at any rate, most of the early variants like SuperGenPass [1] credit mine [2] as the original. And I still use it for low-value sites – but I let iCloud Keychain generate, store, and sync passwords for e-commerce sites and e-mail services, for all the reasons mentioned by others here. [1] https://github.com/chriszarate/supergenpass/wiki/FAQ [2] http…
Does your work predate Stanford PwdHash? https://crypto.stanford.edu/PwdHash/
Maybe! archive.org's oldest capture of my page [0] is from 22 Dec 03, and doesn't have anything for Stanford's until 9 Apr 04 [1]. But I don't think they got the idea from me, since the first links to my page from blogs and aggregators came in Sep 04 after I added the bookmarklet [2].
[0] https://web.archive.org/web/20031222201145/http://angel.net/...
[1] https://web.archive.org/web/20040507195550/http://crypto.sta...
[2] http://jonudell.net/udell/2004-09-07-nic-wolffs-single-signo...
Re: LessPass: sync-less open source password manager
#247I'm the creator of LessPass. We did not expect as many visits on our website. Thank you. We are working on: * encrypt password profiles client side. * help user change their master passwords ( https://github.com/lesspass/lesspass/issues/36 ) * mobile version( https://github.com/lesspass/lesspass/issues/6 ) Change his master password seems to be the biggest problem for many of you. We will address this problem as a pr…
I want to start using this, but I'm concerned what happens when a service changes their domain.
When the domain changes, even subtly like from api.foo.com to www.foo.com, it will break my ability to access the site. If I do not remember the previous URL, I will not be able to recover it.
More details in this github issue comment: https://github.com/lesspass/lesspass/issues/45#issuecomment-...
Has this been a real-life concern for you while you've used the tool?