LessPass: sync-less open source password manager

Post by guillaume20100 » Mon, Nov 07, 2016, 9:01 PM UTC

palant wrote: post #201

guillaume20100 wrote: post #161

Earlier quoted context omitted.

Hi Palant, I found your app in the comment today. So yes, LessPass was developed it independently. And yes we are working in a way to change the number of rounds of PBKDF2. https://github.com/lesspass/lesspass/issues/38 API already evolve ( https://github.com/lesspass/core/commit/70bebd5e5bcd0c9a32ac... ), we are updating the user interface.

I don't think that this is sufficient as long as 8192 is still the default. Personally, I don't think that exposing the number of iteration is a good idea at all - users have no way of knowing how much is enough. Frankly, it took me quite a while to find out what contemporary hardware (especially GPUs) is capable of and how many iterations should be considered safe today.

Post by stcredzero » Mon, Nov 07, 2016, 9:47 PM UTC

Post by woliveirajr » Mon, Nov 07, 2016, 11:57 PM UTC

Quiark wrote: post #182

woliveirajr wrote: post #178

Earlier quoted context omitted.

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…

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.

Post by StavrosK » Tue, Nov 08, 2016, 12:17 AM UTC

problems wrote: post #152

stavros wrote: post #128

Earlier quoted context omitted.

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 passwo…

> 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 you…

Post by woliveirajr » Tue, Nov 08, 2016, 12:35 AM UTC

kgreene2 wrote: post #218

woliveirajr wrote: post #215

Earlier quoted context omitted.

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.