Live data from Hacker News

LessPass: sync-less open source password manager

lesspass.com

181–190 of 247 posts

Re: LessPass: sync-less open source password manager

#181
post #8

Others have expressed most of them, but issues I see with this is: * Algorithm can't be changed/improved without changing all your passwords. * Your master password can't be changed without changing all your passwords. * You have to remember yourself at what sites you are already registered, and in case of critical bug, you would perhaps need to change password at some services (again remembering which ones they were…

Also, some sites (generally banks) change their login URLs and domains from time to time. With a 'traditional' password manager, I can map it to the old login details with a few clicks. With a stateless system, you're out of luck.

Well, you are not forced to use a specificic url or your real login details to generate the password. You could do it with "My Personal Bank Account"+"My alias (not the same as my login)"+MASTER_PASSWORD. It's the same with SSO. You can use "Google Private" or "Google Public" and any login you want to generate a password for your google accounts, without using a real URL nor your real credentials.

Re: LessPass: sync-less open source password manager

#182
post #174

Earlier quoted context omitted.

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…

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.

Re: LessPass: sync-less open source password manager

#183
post #23

Earlier quoted context omitted.

There are a lot of reasonable complaints in the comments, but "you need to change your passwords when changing to this service" is actually not one. You want to do that anyway from time to time, and when you are using a new password manager is actually a great time.

If you want to change your passwords from time to time, as you say, then this system isn't going to suit you, because it only ever generates one password for each site.

You could change your master password from time to time and you chould increase the counter (which changes your password) for a given site from time to time.

Re: LessPass: sync-less open source password manager

#184
I 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://angel.net/~nic/passwd.current.html

Re: LessPass: sync-less open source password manager

#185
post #179
post #76

Earlier quoted context omitted.

>I really like the browser integration, which there isn't anything comparable for pass. people keep saying stuff like this (the one i use because x feature has no real competitor) lastpass. i've used most password managers out there and lastpass hits all these points and more

Command line interface with (or without, for that matter) X integration, and Open Source would be two features it seems to lack.

There is a lastpass cli for the past year...ish:

https://github.com/lastpass/lastpass-cli

Re: LessPass: sync-less open source password manager

#186

I 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/

Re: LessPass: sync-less open source password manager

#187
post #35

While the idea sounds alright (and I've seen similar ideas done before), there are a few problems with this system that make me quite cautious about trying it: * In order to handle different password complexities, regeneration of passwords and similar setting, you have to use a "connected" version (read: you have to store the configuration). In addition, the configuration they have includes potentially sensitive info…

The login you use with lesspass doesn't need to match your actual login on a web site. In fact, nothing needs to match anything real. You could use any url or alias for the service you want to access ie "Google" and you can use your real login or any other text, it doesn't matter as far as you remember it (You could use 'me' for every site, I don't know why this field is required)

Re: LessPass: sync-less open source password manager

#188
post #174

Earlier quoted context omitted.

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…

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

or

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.

Re: LessPass: sync-less open source password manager

#189

Earlier quoted context omitted.

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.

Re: LessPass: sync-less open source password manager

#190

Earlier quoted context omitted.

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

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

Post reply on HN