Hacker News Reader

Comment by JulianMorrison | Hacker News Reader

What 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 serial guessing will break it fast.

3. They don't need any access to you or your stuff, to guess a key. They don't even need access to the server, it can be guessed on an unrelated machine. You don't have the opportunity to detect a break-in and neither does your bank, etc.

4. You only have one password for all the sites, really, underneath, and it's your secret key. If it's broken, it's now a skeleton-key and your digital ass is theirs.

View on HN

I completely agree. What makes all of it even worse is that they only use 8192 iterations of PBKDF2, based on their blog post [1]. To counter GPU-based password cracking, 100,000+ iterations are needed as of 5 years ago [2].

[1] https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4

[2] http://stackoverflow.com/questions/6054082/recommended-of-it...

Yeah, going to Scrypt or Argon2 would mitigate a lot of the GPU-based concerns while still offering reasonable in-browser performance.

Scrypt seems to be performing better in the browser because of 32 bit operations. Argon2 in browser was slow in my tests.

Slow is good for a password hashing function. :P

No. You don't want to use an unnecessarily slow PB-KDF in your daily operations, because that means that the ratio your_speed / attackers_speed is worse.

In other words, you want the KDF that is slowest for an attacker that still completes a KD in, say, 0.5 seconds on your devices.

If it takes 1 sec on my device and 1 year on attackers

versus

If it takes 2 sec on my device and 2 years on attackers

My conclusion

I will spend one second of my life for each login I do, but I'll gain 1 year of security (or the attacker will have to double his power).

Perhaps 5 years to generate, 5 years to break isn't usefull (and the ratio would be terrible).

But keeping the same ratio, or even making it a little worse when it makes the attacker take longer, doesn't seem bad.

No, dom0 is right.

You are spending 2sec computing the result in browser JavaScript. The attacker will throw JS out of the window and spend 0.01sec in hand-optimized C++ or OpenCL code. You gain no security.

Don't get it, would you mind to elaborate?

Because, IMHO, the attacker will always use optimized resources. Be it algorithm, cpu speed, gpu, and so on. If I double the number of interactions, it'll take more or less twice the time. For me or for the attacker. So I'll trade twice my time vs twice his time.

He can reduce his time having more cpu, gpu or finding a better algorithm.

Argon2 is slow in the browser, but isn't an inherently slow algorithm.

In other words, you have two algorithms that will each take 1 year on an attacker's machine. Option A takes 1 second on your machine, Option B takes 2 seconds. Option B isn't any better. In fact, it's worse, because it only compromises user experience and potentially leads people down the path of assuming it's more secure than it is.

Oh, so we're talking about different things (not exactly with you, but in the conversation)

I was thinking about the number of interactions (or any other tunable parameter) in the same algorithm, like Scrypt or bcrypt or PBKDF2.

Of course, you're completely right on your example: change one for another that increases time just in browser doesn't give any gain. It must be harder to the attacker...

A better comparison for this situation would be:

1 second in my browser and 1 year to bruteforce on attacker's server cluster

v.s.

0.5 seconds in my browser and 1 year to bruteforce on attacker's server cluster

1 second in my browser and 2 years to bruteforce on attacker's server cluster

The idea is to choose the method that is most efficient for you, because doing so allows you to choose a work factor that makes things harder for the attacker without sacrificing usability.

For reference, I am the author of Easy Passwords extension which uses a very similar concept.

Your concerns are valid of course but not necessarily for PBKDF2 which is used here. As long as a significantly high number of iterations is used bruteforcing any non-trivial master password from a derived one would take so long that it becomes unrealistic. Of course, ideally you should pick a strong password as your master password (Easy Passwords actively encourages that), it would also be recommendable with an encrypted key store. LessPass uses merely 8192 iterations however, this is way too low - recommendations vary but I would consider anything below 100k insecure these days. But with a sufficient number of iterations and a strong master password your biggest worry by far should be a malware infestation on your computer - both with this approach and with an encrypted key storage.

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 highly sensitive accounts, is very important. With this approach, you can't change any one of your passwords without changing the whole lot (i.e. changing your master password) which simply isn't practical.

7. They serve the whole thing over the web, which, as has been pointed out many times over the web[1], is a bad idea.

Overall, its seems like they are looking for a overly simplistic solution for a complicated problem.

<shameless plug>Padlock[2] is a penetration-tested, open source password manager that, while using a battle-tested, 'conventional' encryption scheme for securing data, still tries to be forward thinking and to improve on the overall user experience of other password managers.</shameless plug>

[1]https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

[2]: https://padlock.io

For reference, I am the author of the Easy Passwords extension which uses a similar concept.

5. The user-specific part is the user name. As long as these two users don't use the same user names they won't have the same passwords.

6. Password generators typically solve this by implementing a revision counter that you can increase in order to generate a new password. LessPass has this functionality, can be seen in screenshots.

7. What is served over the web? LessPass is a browser extension, the page you see in screenshots is contained in the extension.

I obviously disagree with your conclusion. Password generators are a very nice tool, and LessPass isn't currently using the full potential of the idea. For example, Easy Passwords allows you to create a "paper backup" of your passwords - all the password metadata (website, user name, password length) is safe to be printed, yet as long as you remember your master password it is sufficient to recreate your passwords. Of course, occasionally you simply cannot change a password which is why Easy Passwords has a hybrid concept and allows storing some passwords in encrypted form (no paper backup there).

Thanks for adding some clarity here. Apparently I missed some of the finer details.

> What is served over the web?

There is a form for generating passwords right on the front page and it states nowhere that the browser extensions are the more secure / recommended way of using the tool.

Ah, I see. Yes, I have a similar one for Easy Passwords under https://palant.github.io/easypasswords/online.html - but it has a huge warning on it. This is not secure indeed and the recommended way of using that page if you absolutely have to is downloading it to your hard drive.

>they will basically have all the same passwords for every site!

Not if the generated password also depends on your username.

5) You can't change the password (I guess they could include a counter, but then you need to remember or sync that.)

There is indeed a counter, with the shortcomings you mentioned.

Additionally,

You can't change your master password unless you go and change every single password you use.

You won't be able to use it on sites with abnormal password requirements (usually bad practices on the part of the site admins but that doesn't mean you can just ignore it).

Schwab used to have (and may still) a maximum password length of 8 chars. Crazy—especially for a site with financial/sensitive information.

Good ol' hunter2, I use it for all my logins

> Good ol' * * * * * * * *, I use it for all my logins

hey, if you type in your pw, it will show as stars

These weaknesses all hold if it's discovered that lesspass is in use. How would information that the user is using lesspass leak?

The GP's points are all a bit weak, especially if this method uses a good KDF like bcrypt to generate the keys.

I used SuperGenPass for a while, before switching to KeePass, and the major drawbacks I found were:

1) No way to change a password. None at all. If a site required you to make up a new password, you're out of luck (or you have to come up with a new master password every time and remember which master password to use for which site).

2) If a website is incompatible with the generated password, you're out of luck. My bank (because of course it would be the bank, cat sharing websites are more secure) would throw a fit because I had a number in my password and refuse to set it.

3) If someone has a keylogger or otherwise steals your master password, you're done for everywhere. This is not so with password databases, because the attacker also needs the file.

4) It's just not really that much more convenient than KeePass + KeePassAndroid. Hell, the latter is more convenient because I don't have to keep retyping my password, I can store it in memory protected by my fingerprint, which is something that no SuperGenPass-compatible app I've found does.

In summary: Go with KeePass, it's better.

> 3) If someone has a keylogger or otherwise steals your master password, you're done for everywhere. This is not so with password databases, because the attacker also needs the file.

It's about equivalent though. If someone can keylog you, they can probably obtain the file. If that's through malware then they simply grab the file with the malware, if that's through a hardware keylogger then they just grab it off your machine when you're not around. Even if you used FDE, you're dead in the water because they logged your FDE password too.

Heck, if I were the malware author I'd inject into KeePass or similar and dump your decrypted database as soon as you login, immediately bypassing any anti-keylogger tools, keyboards, alternative authentication methods for your password manager, etc that you might have used.

It's important to think about realistic threat models with things like this. If you're keylogged you're already screwed unless you use your password database on a separate machine.

Sure, a much more plausible model is that you reuse the master password somewhere vulnerable and it's game over.

But that's trivially mitigated - don't.

#2 - the password generation options are part of the input to the generation function for LessPass. Problem of course is that you have to either remember those or store them somewhere, at which point you might as well store the password database.

Bcrypt is not really a KDF, it's a strong hash generator + verification processor rolled into one for easy consumption.

See PBKDF2 / RFC2898 for tooling appropriate to generate an expensive-to-generate cryptographic key from a user-supplied passphrase.

In principle you could add a post-generation step that takes a description of the site's particular brand of password limitation damnfoolery and munges the output to fit. Then this profile would need to be saved somewhere so the same step could be done at password filling time.

(Still less sensible than doing this once and encrypting the result.)

If there's any format regularity in the output, like it's in one of the PKCS message formats, that could be detected. Or if it's a fixed length that could give it away.

Webcam hack. Social engineering. Binoculars. All the things.

Just sweeping them up en masse and trying popular keys.

> If there's any format regularity in the output, like it's in one of the PKCS message formats, that could be detected.

After entering some junk data, and incrementing the counter field, /every/ generated password has started with one of [aeiouy], so there clearly is some regularity in the output, and I guess more if analysed in detail.

Same here, it seems like every password starts with one of these [aeiouy] characters. So it seems these passwords are not as safe as they seem. Brute force may not be necessary to break these passwords. Is there any alternative services out there that require no storage?

I posted an issue: https://github.com/lesspass/lesspass/issues/51

I suspect that if a hacker were focused on a person (say a person under investigation or a celebrity), they could simply use that as one of many strategies in compromising the password.

I completely agree. In addition to that, I use my password manager (LastPass) to:

A) Safely store confidential data like credit card information and pins.

B) Share some data with coworkers, on a folder-by-folder basis.

C) In a case something happens to me, my friend has Emergency Access after 7 days: https://helpdesk.lastpass.com/emergency-access/

I think these concerns are slightly misleading. 2., 3. and 4. boil down to 1.

1. is a problem. If one password is compromised it is possible to brute force the master password. This is mitigated by a key-derivation function.

2. is also mitigated by a key-derivation function. Also you still need to test the guesses, which requires knowing one password or trying to log into a website. The second option should be equivalent to compromising one password via brute force.

3. is not true, they need to know a password or try to log into a website for every guess.

4. Again, this is only true if one site password is compromised.

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.

I agree with you and will not be using this tool. but it does seem like a good tool for those that do not want to use a password manager. (better than nothing for sure)

The attacker would have to know that you are using this tool, and they would have to know what you input for the site name and your username/password. So basicly you have three passwords for each site.

It would appear to be cryptographically pretty much identically secure as using a single password on all sites, if someone knows who they are targeting and what website. And less secure than having two passwords, your regular one and your Super Sekrit one for Amazon and the bank.

> It would appear to be cryptographically pretty much identically secure as using a single password on all sites

How? If a single password is used then if any of the sites is untrustworthy or stores the password insecurely (for example as plain text) or if the connection can be intercepted or the server is hacked an attacker directly gets access to all other sites.

With the derived password this is only the case if the derivation algorithm can be attacked/the master password can be recovered successfully. So it still seems to be an improvement over a shared password.

> It would appear to be cryptographically pretty much identically secure as using a single password on all sites

I don't think this is true. To brute force the master password, you need to know the password of one site.

Oy... The generated passwords are a repeating sequence like abCD9?wxYZ7% - the aaZZ9+ pattern repeats and the keyspace is smaller than it should be.

Simple. encrypt the website with a second key before passing it to the HMAC function.

Reply on news.ycombinator.com