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.
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].
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>
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).
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.
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.
I really dislike the copy/marketing of this tool. OK, so it doesn't sync? How does it work? reads whole front page and all features.
No sync, but access anywhere? How does it work?? *clicks the "How it works" link and reads another 5 paragraphs of "This is great. It's so simple. It works really really well. You can phone people and they'll tell you how well LessPass works". Finally, after clicking on the link and scrolling past a bullet list and stylised quotation, we get
"The trick is to compute passwords rather than generate and store random passwords.
LessPass generates unique passwords for websites, email accounts, or anything else based on a master password and information you know."
"Next-gen", "Anywhere, anytime", "Manage directly from your browser". These are all super cliched, really cheap phrases that I really dislike. The front page is full of them. If you're marketing a luxury yacht trip to people with more money than sense, then sure you're probably going to get good results by writing like this. But the folk reading about this are going to be pretty technical and I'm sure everyone would appreciate to see something like "We provide a function that generates a memorable password from the site name and your master password" on the front page, above the fold.
In terms of entropy, you may as well come up with your own function. Security through obscurity is bad (no one knows the function you use to generate site specific passwords) but it's better than security through less obscurity (use a public function that a bunch of other people are using).
You can't get free entropy. If you care about your passwords not being broken when a database of hashes is dumped, you need to use a long, securely generated, random password. Sure, this is better than using the same password everywhere, but it's not really an alternative to something that uses proven cryptography to generate secure unique passwords. Passwords generated using this are only as good as your master password, with some obscurity thrown in.
Obviously you are not the target audience for the main website; it explains how it works in general terms, i.e. what concepts should I know to understand its purpose and usage; not how it works from a technical perspective.
I only wish more open source websites followed this same approach, as it is the best way to introduce the tool to a public that may not know very well what a password manager is good for or how to use it properly.
You probably should jump directly to the github project page[1], where you'll find that kind of technical description that you were expecting and didn't find.
Agree with thought on implementation, but at least on mobile the. It about how it actually works is right below the first few marketing blurbs. Not that egregious.
I don't have the time to figure out how it works, but I bet it uses the same principle that I presented about 3 years ago (basically there is a "master password"):
It's great people are exploring this problem space, but so far nothing comes close to https://www.passwordstore.org/ which is just a wrapper around gpg and git. It has Android/iOS clients, as well as GUI clients.
On Android I use Password Store + OpenKeychain, the UX with a YubiKey is very smooth.
I was using this for ~4 years and really liked it, but recently I've been using 1Password. I tried 1Password as it has a family plan, that didn't really work out though (getting non-technical people to use a password manager is hard - so I'll forever keep being asked "What's the Netflix password?"), but I have stuck with it for myself.
I really like the browser integration, which there isn't anything comparable for pass. I had a bash script [0] which when run would pull the current URL from my browser, and run pass to generate or copy the password to the clipboard - but the 1Password extension is so much nicer. If I'm on a site with weird requirements I'd have to figure out the params to make pass generate a password which matched it; with the extension I just click a few buttons.
I've also got hooked on the iOS app. I didn't know there was one for pass, but it looks rather basic compared to 1Password [1]. 1Password also supports TOTP, so you don't need a seperate app for that - although for security you probably should.
Maybe one day I'll get around to writing my own extension and app for pass, but for now paying $60/year is worth it for me. I don't pay for many apps/services, but this I find really worth it.
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).
With that said, I really like the outside-of-the-box thinking on this.
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?
Thing is: There's a solution for all these problems: All you have to do is actually generating a random password and store that (in-fact, that's the solution proposed by LessPass to use for these special cases. But if you have storage for the special cases, why not just store the passwords to begin with?)
You don't want to sync it because you don't trust the client-side encryption used in all the managers out there? Use a piece of paper to write the passwords down. Or use a device you constantly carry with you as your password store.
While there are tons of workarounds for the issues of stateful password managers, there are none for the stateless ones (aside of storing the state somewhere, but if you're doing that, why not just store the password?)
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.
I was quite surprised to see your extension, it is very similar to my Easy Passwords extension in both concept and design. I've had a brief look at the source code and I guess that it was a completely unrelated development after all?
Please increase the number of iterations, PBKDF2 with 8192 iterations is a very bad idea in year 2016. I would consider 100k iteration the lower limit, my Easy Passwords extension uses 256k. For reference, I described the threat scenario here:
Note that LastPass isn't a good example when it comes to security-relevant decisions. If you are interested, I published a lengthy writeup under https://security.stackexchange.com/a/137307/4778.
I don't know what these are used for, but secret keys generated from current time are easy to guess. You only have to try around 2^24 values if you can estimate installation time within a specific year.
We need to re-think passwords. Password re-use is a big problem for technical and non-technical users alike, because managing a unique generated password between devices is hard. Dealing with password managers and syncing password lists back and forth is super frustrating to users. None of the existing tools work quickly and easily on all the different devices a user could be using, so at some point everyone that uses a password manager is going to be stuck fighting their password manager to log into a website. The user will likely perform a password reset, which will send an email that allows the user to bypass the password entirely.
Why not provide people with a quick and easy "login by email", since this fallback is almost always available anyway? Slack does this https://auth0.com/blog/how-to-implement-slack-like-login-on-... and allows people to have accounts with no password memorization. You're not making the login any less secure - any attacker with access to a user's email can almost always perform a password reset anyway.
Given that you already have dozens of site with their own passwords, you just can't import your passwords, but you need to change all of them to start using lesspass first.
Also, if the way the generation of passwords works changes later (i.e. bug), then the users are stuck with a version, or the bug is never fixed, ever.
You are right. I made me similar tool. It just made MD5 out of mater password and service name.
You suddenly realize how many services have special rules you can't fit in. So for each service, I had to remember master password, which "url" i used (gmail.com or mail.google.com?) and which restrictions apply. Usually they did not allow me so long password. Sometimes I was limited to 16, sometimes 12 chars.
After big password leak (heartbleed), I had to setup second master password for all affected service.
So, no. No more sync-less state-less password managers for me.
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.
I am surprised Stanford PwdHash [0] has not been mentioned yet as an alternative, which has extensions for Chrome, Fx, Safari, Android, iOS, Terminal and other software.
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 information (password length, number of times password was changed, list of websites I use, my username on the site). And currently those profiles are unencrypted. So you in order for it to be useful it's no longer sync-less. As an aside, my bank (foolishly) uses my generated username as a "privileged" piece of information -- which means that I literally could not use this manager for my bank.
* You can't change your master password without updating all of your site passwords. This also means you can't import your old passwords without just changing them all. IMO this makes LessPass not a password "manager". It's a password generator.
* Also, the profile doesn't appear to contain any configuration details for the PBKDF, which seems like a bad idea (it means that they can never practically update the PBKDF without introducing backwards compatibility in the profile settings). Also not sure why they're using SHA when there are better password hashing algorithms.
* Aliases are impossible to implement (without adding more information to the profile), which just makes this impossible to use with SSO systems (I'm not going to remember which of the 5 different hostnames I used to generate a password I use once a year).
I've got to admit that I kinda like the symbols shown next to your password to make sure you're using the right master password, but there doesn't seem to be any description how that's generated. My guess is that it's similar to SSH keyart (which then brings up the question how often will collisions happen with only X^3 options, and can you have two passwords result in different orderings of the same tokens).
Overall, seems like an okay idea. But I would prefer if someone just offered a nice way to host your KeePass databases (or rather if there was an app that did it). You could probably do it with git and push to GitLab or something, but that is just ugly to do manually.
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)
Don't use this if you're ever going to type in a password where the screen might be shared -- the constantly-updating "is my password correct" glyphs give away enough information to make it super trivial to decode by eye.
PS: the password for the demonstration gif is "passwordpassword"
The _prettyPrint [1] and _getPasswordTemplate [2] functions they use to get from the HMAC to the actual password seem to have a lot of issues:
- _prettyPrint calls into _getPasswordChar which will then take the character code modulo the length of the array of possible characters [3], which is usually going to be biased if the character code is not uniformly distributed between 0 (inclusive) and a multiple of the length (exclusive).
- It's even worse because the input to _prettyPrint is the HMAC encoded as a hexadecimal string. The impact of this depends on the size of the possible character array, but in several cases, some of the options can never be chosen and others will be chosen twice as often as others that can be chosen.
- Using the hex encoding also drastically reduces the number of possibilities for a given length even if that input was then used in a less flawed fashion.
- _getPasswordTemplate appears to treat a password with lowercase/uppercase letters as a series of alternating vowels and consonants (by appending 'vc' or 'VC' to the password template).
- It also generally seems to define "password containing X and Y char types" as "password containing X char type, then Y char type, then X, then Y, and so on".
I've used PasswordMaker in the past which uses the same concept but recently moved away from it. Changing passwords is a pain as you now have to remember special parameters for certain pages. Even worse, in case of a compromise of your master password, you're toast. The same is true when losing your password manager database + credentials, but at least you will have a list of all your compromised records which you would have to keep separate in this case.
I've moved to KeeWeb since then + CPK for Chrome and Keepass2Android on my phone and couldn't be happier.
I wouldn't use a password manager system that doesn't have the ability to change the master password.
EDIT: You can't change any password really, without changing all of them (or having a separate master password). Seems unpractical as soon as, for example, site X gets its database hacked.
I 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...)
One issue with this is that URLs for sites can, and in my experience, often do, change, while logins remain the same. A password that uses the URL/site itself may no longer work unless you can remember the old site. That's a headache. I used to have my own mental model of generating a password based on a URL, and it eventually failed several times over because of this issue.
[+] [-] JulianMorrison|9 years ago|reply
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.
[+] [-] obi1kenobi|9 years ago|reply
[1] https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4
[2] http://stackoverflow.com/questions/6054082/recommended-of-it...
[+] [-] palant|9 years ago|reply
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.
[+] [-] MaKleSoft|9 years ago|reply
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
[+] [-] jimktrains2|9 years ago|reply
[+] [-] homulilly|9 years ago|reply
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).
[+] [-] grhino|9 years ago|reply
[+] [-] ZeljkoS|9 years ago|reply
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/
[+] [-] whyever|9 years ago|reply
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.
[+] [-] StephenConnell|9 years ago|reply
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.
[+] [-] ahazred8ta|9 years ago|reply
[+] [-] russdill|9 years ago|reply
[+] [-] sixhobbits|9 years ago|reply
"The trick is to compute passwords rather than generate and store random passwords.
LessPass generates unique passwords for websites, email accounts, or anything else based on a master password and information you know."
"Next-gen", "Anywhere, anytime", "Manage directly from your browser". These are all super cliched, really cheap phrases that I really dislike. The front page is full of them. If you're marketing a luxury yacht trip to people with more money than sense, then sure you're probably going to get good results by writing like this. But the folk reading about this are going to be pretty technical and I'm sure everyone would appreciate to see something like "We provide a function that generates a memorable password from the site name and your master password" on the front page, above the fold.
In terms of entropy, you may as well come up with your own function. Security through obscurity is bad (no one knows the function you use to generate site specific passwords) but it's better than security through less obscurity (use a public function that a bunch of other people are using).
You can't get free entropy. If you care about your passwords not being broken when a database of hashes is dumped, you need to use a long, securely generated, random password. Sure, this is better than using the same password everywhere, but it's not really an alternative to something that uses proven cryptography to generate secure unique passwords. Passwords generated using this are only as good as your master password, with some obscurity thrown in.
[+] [-] TuringTest|9 years ago|reply
I only wish more open source websites followed this same approach, as it is the best way to introduce the tool to a public that may not know very well what a password manager is good for or how to use it properly.
You probably should jump directly to the github project page[1], where you'll find that kind of technical description that you were expecting and didn't find.
[1] https://github.com/lesspass/lesspass
[+] [-] michaelmior|9 years ago|reply
[+] [-] rco8786|9 years ago|reply
[+] [-] gtrubetskoy|9 years ago|reply
http://grisha.org/blog/2013/05/31/simple-solution-to-passwor...
[+] [-] adilparvez|9 years ago|reply
On Android I use Password Store + OpenKeychain, the UX with a YubiKey is very smooth.
https://fossdroid.com/a/openkeychain.html https://fossdroid.com/a/password-store.html
[+] [-] lucaspiller|9 years ago|reply
I really like the browser integration, which there isn't anything comparable for pass. I had a bash script [0] which when run would pull the current URL from my browser, and run pass to generate or copy the password to the clipboard - but the 1Password extension is so much nicer. If I'm on a site with weird requirements I'd have to figure out the params to make pass generate a password which matched it; with the extension I just click a few buttons.
I've also got hooked on the iOS app. I didn't know there was one for pass, but it looks rather basic compared to 1Password [1]. 1Password also supports TOTP, so you don't need a seperate app for that - although for security you probably should.
Maybe one day I'll get around to writing my own extension and app for pass, but for now paying $60/year is worth it for me. I don't pay for many apps/services, but this I find really worth it.
[0] https://github.com/lucaspiller/passosx
[1] https://github.com/davidjb/pass-ios
[+] [-] omtose|9 years ago|reply
[+] [-] Ajedi32|9 years ago|reply
YubiKey support looks pretty nice though; I'm not sure there's an easy way to do what with KeePass.
[+] [-] croon|9 years ago|reply
* 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).
With that said, I really like the outside-of-the-box thinking on this.
[+] [-] pilif|9 years ago|reply
Thing is: There's a solution for all these problems: All you have to do is actually generating a random password and store that (in-fact, that's the solution proposed by LessPass to use for these special cases. But if you have storage for the special cases, why not just store the passwords to begin with?)
You don't want to sync it because you don't trust the client-side encryption used in all the managers out there? Use a piece of paper to write the passwords down. Or use a device you constantly carry with you as your password store.
While there are tons of workarounds for the issues of stateful password managers, there are none for the stateless ones (aside of storing the state somewhere, but if you're doing that, why not just store the password?)
[+] [-] guillaume20100|9 years ago|reply
* 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 priority.
[+] [-] SimplGy|9 years ago|reply
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?
[+] [-] palant|9 years ago|reply
Please increase the number of iterations, PBKDF2 with 8192 iterations is a very bad idea in year 2016. I would consider 100k iteration the lower limit, my Easy Passwords extension uses 256k. For reference, I described the threat scenario here:
https://palant.de/2016/04/20/security-considerations-for-pas...
Note that LastPass isn't a good example when it comes to security-relevant decisions. If you are interested, I published a lengthy writeup under https://security.stackexchange.com/a/137307/4778.
[+] [-] avian|9 years ago|reply
https://github.com/lesspass/lesspass/blob/master/lesspass.sh...
[+] [-] mgliwka|9 years ago|reply
EDIT: I've created a issue on GitHub about this. (https://github.com/lesspass/lesspass/issues/43)
[+] [-] lloeki|9 years ago|reply
[+] [-] fps|9 years ago|reply
Why not provide people with a quick and easy "login by email", since this fallback is almost always available anyway? Slack does this https://auth0.com/blog/how-to-implement-slack-like-login-on-... and allows people to have accounts with no password memorization. You're not making the login any less secure - any attacker with access to a user's email can almost always perform a password reset anyway.
[+] [-] whyever|9 years ago|reply
There was Mozilla's Persona (which was shut down a few days ago). Now there is this:
https://portier.github.io/
[+] [-] jiehong|9 years ago|reply
Given that you already have dozens of site with their own passwords, you just can't import your passwords, but you need to change all of them to start using lesspass first.
Also, if the way the generation of passwords works changes later (i.e. bug), then the users are stuck with a version, or the bug is never fixed, ever.
[+] [-] czechdeveloper|9 years ago|reply
You suddenly realize how many services have special rules you can't fit in. So for each service, I had to remember master password, which "url" i used (gmail.com or mail.google.com?) and which restrictions apply. Usually they did not allow me so long password. Sometimes I was limited to 16, sometimes 12 chars.
After big password leak (heartbleed), I had to setup second master password for all affected service.
So, no. No more sync-less state-less password managers for me.
[+] [-] erikb|9 years ago|reply
[+] [-] b15h0p|9 years ago|reply
[+] [-] romseb|9 years ago|reply
[0] https://pwdhash.com/
[+] [-] cyphar|9 years ago|reply
* 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 information (password length, number of times password was changed, list of websites I use, my username on the site). And currently those profiles are unencrypted. So you in order for it to be useful it's no longer sync-less. As an aside, my bank (foolishly) uses my generated username as a "privileged" piece of information -- which means that I literally could not use this manager for my bank.
* You can't change your master password without updating all of your site passwords. This also means you can't import your old passwords without just changing them all. IMO this makes LessPass not a password "manager". It's a password generator.
* Also, the profile doesn't appear to contain any configuration details for the PBKDF, which seems like a bad idea (it means that they can never practically update the PBKDF without introducing backwards compatibility in the profile settings). Also not sure why they're using SHA when there are better password hashing algorithms.
* Aliases are impossible to implement (without adding more information to the profile), which just makes this impossible to use with SSO systems (I'm not going to remember which of the 5 different hostnames I used to generate a password I use once a year).
I've got to admit that I kinda like the symbols shown next to your password to make sure you're using the right master password, but there doesn't seem to be any description how that's generated. My guess is that it's similar to SSH keyart (which then brings up the question how often will collisions happen with only X^3 options, and can you have two passwords result in different orderings of the same tokens).
Overall, seems like an okay idea. But I would prefer if someone just offered a nice way to host your KeePass databases (or rather if there was an app that did it). You could probably do it with git and push to GitLab or something, but that is just ugly to do manually.
[+] [-] 5xman|9 years ago|reply
[+] [-] sonofgod|9 years ago|reply
PS: the password for the demonstration gif is "passwordpassword"
[+] [-] spb|9 years ago|reply
[+] [-] guillaume20100|9 years ago|reply
[+] [-] ekiru|9 years ago|reply
- _prettyPrint calls into _getPasswordChar which will then take the character code modulo the length of the array of possible characters [3], which is usually going to be biased if the character code is not uniformly distributed between 0 (inclusive) and a multiple of the length (exclusive).
- It's even worse because the input to _prettyPrint is the HMAC encoded as a hexadecimal string. The impact of this depends on the size of the possible character array, but in several cases, some of the options can never be chosen and others will be chosen twice as often as others that can be chosen.
- Using the hex encoding also drastically reduces the number of possibilities for a given length even if that input was then used in a less flawed fashion.
- _getPasswordTemplate appears to treat a password with lowercase/uppercase letters as a series of alternating vowels and consonants (by appending 'vc' or 'VC' to the password template).
- It also generally seems to define "password containing X and Y char types" as "password containing X char type, then Y char type, then X, then Y, and so on".
[1]: https://github.com/lesspass/core/blob/master/lib/index.js#L8...
[2]: https://github.com/lesspass/core/blob/master/lib/index.js#L6...
[3]: https://github.com/lesspass/core/blob/master/lib/index.js#L1...
[+] [-] ch0wn|9 years ago|reply
I've moved to KeeWeb since then + CPK for Chrome and Keepass2Android on my phone and couldn't be happier.
[+] [-] Ruphin|9 years ago|reply
Your master password is 'passwordpassword'. 10 points if you know how I figured that out :)
[+] [-] PuffinBlue|9 years ago|reply
Quite an interesting example of how easy it is to slip up and make something trivially crackable.
[1] https://github.com/lesspass/lesspass/issues/48
[+] [-] corobo|9 years ago|reply
I like the idea don't get me wrong, I just can't see all of the downsides right now which will stop me using it.
Elephant in the room: Are you going to be sued by lastpass for the name?
[+] [-] HackinOut|9 years ago|reply
EDIT: You can't change any password really, without changing all of them (or having a separate master password). Seems unpractical as soon as, for example, site X gets its database hacked.
[+] [-] viralpoetry|9 years ago|reply
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...
https://github.com/viralpoetry/password-generator
[+] [-] hellofunk|9 years ago|reply
[+] [-] wyclif|9 years ago|reply