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.
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 2 sec on my device and 2 years on attackers
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.
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.
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.
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...
1 second in my browser and 1 year to bruteforce on attacker's server cluster
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.
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.
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, is a bad idea.
Overall, its seems like they are looking for a overly simplistic solution for a complicated problem.
<shameless plug>Padlock 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>
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).
> 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.
Not if the generated password also depends on your username.
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).
hey, if you type in your pw, it will show as stars
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.
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.
See PBKDF2 / RFC2898 for tooling appropriate to generate an expensive-to-generate cryptographic key from a user-supplied passphrase.
(Still less sensible than doing this once and encrypting the result.)
Webcam hack. Social engineering. Binoculars. All the things.
Just sweeping them up en masse and trying popular keys.
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.
I posted an issue: https://github.com/lesspass/lesspass/issues/51
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/
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.
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.
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.
I don't think this is true. To brute force the master password, you need to know the password of one site.
"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.
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, where you'll find that kind of technical description that you were expecting and didn't find.
First, I think I am pretty representative of the target audience for the main website (it's sad, but most non technical people still don't know what a password manager is or why they might want to use one).
Second, there is a difference between "What it does" (A password manager that re-computes the same site-specific password on every use, meaning that no syncing of passwords is necessary) which you can still make pretty informative vs "Me telling you why you should use it" (The cliches I quoted). Even if the website was aimed at those with zero technical knowledge, it could still give more concrete detail on what it is and why you need it rather than the empty marketing phrases.
The github repo should be where I go if I want to know what hashing libraries they're using, if their Math checks out, and who the contributors are. Not if I just want to know what it actually is (apart from "The best ever super duper password manager that you really need to download right now before tomorrow") and kind-of-how it works.
Maybe they're trying to make a website for non technical people, in order to gain some traction among that audience?
If developers keep pandering to the technical audience who already knows enough about the purpose of password lockers, you have a circular problem where the general audience never learns about them.
And remember, marketing phrases exist because they work. If you don't know what a product is good for, the seller needs to state it in plain terms in order to convince the customers of how it could benefit them.
"how it works" should show you the internals
"what it does" is better description if you are just going to tell me the inputs and outputs.
"It does not save your passwords in a database.
It does not need to sync your devices together.
"The system uses a pure function, i.e. a function that given the same parameters will always give the same result. In our case, given a login, a master password, a site and options it will returns a unique password."
I don't think this is relevant. You still need to inverse the key-derivation function. If you know a hundred passwords, this will be technically easier than if you know one password, but it should not matter if the security margin of the key-derivation function is high enough.
No, LessPass uses PBKDF2 which is already a lot better than merely SHA-512. However, with 8192 iterations it still makes guessing the master password too easy.
Someone commented on my article then that you can pretty much accomplish this from the command line with:
> echo "masterpassword gmail" | md5
> md5sum | cut -d" " -f1
or similar. Carriage-return followed by ctrl-D to exit. Output matches echo "whatever" | md5sum | cut -d" " -f1 in my term.
On Android I use Password Store + OpenKeychain, the UX with a YubiKey is very smooth.
I really like the browser integration, which there isn't anything comparable for pass. I had a bash script  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 . 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.
It goes way beyond "probably should" regarding security. You're giving a single company not only potential access to your usernames and passwords, but also your last line of defense - TOTP generation. That combination of apps put everything in reach of one company to fuck you over.
Using a password manager that is being coded and maintained by a random everyday software company should be the only concern anyone has over even considering using such an app. That one company has the ability - whether intentionally or via being hacked - to release an update to any of their client apps that sends your entire database, decrypted to plaintext, to any server in the world.
Can you think of any scenario where someone slips in a 2-line commit to one of their client apps that sends your decrypted database to any server of their choice? We're talking about one disgruntled employee who decides they would like access to millions of users' most sensitive credentials. Or perhaps a single firewall opening or social engineering attack away.
It blows my mind that anyone would put this much trust in any for-profit password manager. Every month we hear about yet another major hack against software companies. One day soon, such a hack will happen to 1Password or LastPass, and the majority of their customers are going to have their entire lives (logins to bank accounts, government portals, etc.) exposed.
Such an eventuality cannot be defended against. It will start and end in less than 48 hours thanks to auto-updating applications, and will affect millions.
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
If the worst comes to worst, I'll probably move to Dashlane (which is significantly more expensive & a bit more work to use - extensions won't work without a desktop app)
I've used 1P for a few years without looking at the competition, so curious to hear what they can do.
1. It required a desktop app to be installed to use the clients (while this is an issue with Dashlane, the 1Password windows desktop client is just weird - looks outdated, crashes etc.)
2. The 1Password Android app seemed to not have in-app password fill in (which both Dashlane & Lastpass had). While it's not too much of an inconvenience, I feel like 1Password is great if you are in the apple ecosystem.
This is not to say 1Password is "bad" by any means...I loved it's dropbox sync feature for example and it's integration with Alfred on Mac was awesome!
I understand that 1password on iOS doesn't interact as a third party keyboard, and 1password is an iOS/mac app first and foremost, but that's no excuse for making their Android UX so incredibly frustrating.
My understanding is that Chrome makes it difficult to have this kind of thing due to it's sandbox. There was some talk of exposing pass over the network locally so there were no sandbox concerns.
How does this work? I don't suppose there's a micro format for password requirements? Does 1password just have a database of password formats for popular websites?
freepass  seems like it could be a potential candidate, somewhere between pass and LessPass, but I haven't tried it out for myself yet.
Also full disk encryption.
Full disk encryption also doesn't prevent a running application from seeing the directory structure. But I guess this is not a very realistic attack vector.
Encryption all the way down.
YubiKey support looks pretty nice though; I'm not sure there's an easy way to do what with KeePass.
It can securely save files, generate passwords, save passwords and optionally can sync using git.
Nevermind, I think I've got it (https://github.com/davidjb/pass-ios) but is there a no-jailbreak option?
* 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.
These issues are definitely solvable, at least if you use a hybrid concept: while most passwords are generated, some can be encrypted and stored (encryption key derived from the master password). Easy Passwords has this functionality and LessPass appears to be working on it as well. Then changing algorithm or master password can be done by converting all existing generated passwords into stored password. This isn't a great solution of course and so far I haven't seen the need to implement this escape hatch but it can be done if absolutely necessary.
As to remembering the websites where you registered - that should definitely be the job of the extension (not storing passwords doesn't mean that you cannot store metadata). And many password generators support a revision counter for passwords, you increase it when you need a new password.
I could not agree more with the points you mentioned.
To solve the last one I added the option to create an encrypted list for the sites. But so you end with an additional password you need to remember because using the same as for the masterkey makes this the only key to access every password. And this is what the system tries to avoid.
If you compare this to two factor authentication it's the same amount of extra work, but without the benefits.
You should also avoid copying passwords to the clipboard as many applications and even web sites might have access to it.
Too bad client certifications are deprecated, now when SSL/TSL is becoming more and more popular. Only downside with client certificates is that you have to copy the key (witch can be password protected) to all your devices. Another downside was that the site required SSL/TSL, but almost every site have that now!
Personally I'd love to see UAF or SQRL take off. Lots of potential there.
As a work flow nit-pick, what if the password requirements change? You need to remember the original settings to generate your password, but if the site now says "must include numbers" when it didn't before...
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?)
Passwords are not easy. My current solution for the long tail of things that need passwords is two factor + really strong password I generate then don't save anywhere. If I get signed out I do password reset to my gmail. Gmail is two factor (obviously) with a really strong password and recovery email to an email address nobody knows.
This is still a huge pain though.
If you use a paper based solution, just alter the passwords you write down using some additional information only known to you - maybe some prefix or suffix and the list would be useless for an attacker.
If you think they can force you to divulge the master password or your password scheme if you're using paper (they probably can, see https://xkcd.com/538/), then LessPass won't be of any help to you either.
I think the biggest issue still is what happens when you change your master password? Because I couldn't find an answer for that.
>aside of storing the state somewhere, but if you're doing that, why not just store the password?
Because even if the state information is compromised, it is useless to the attacker. On the other hand, if a password is leaked that can be used to access the account.
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!
1. because compromises do not give up the password
2. because storage then becomes optional, it's still usable if it's not installed on the device you're using, as long as you remember the metadata. (or keep trying different combinations until you get it, there aren't that many different combinations as long as you rarely increment a counter).
Unless of course by "compromise" you meant the master password being stolen, in which case such a compromise would result in all your passwords being stolen with both types of password managers.
* 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.
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?
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.
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.
EDIT: I've created a issue on GitHub about this. (https://github.com/lesspass/lesspass/issues/43)
$ xxd -l 20 -p /dev/random
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.
There was Mozilla's Persona (which was shut down a few days ago). Now there is this:
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 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.
* 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.
"You can put whatever you want in field X" is not a solution to the problem IMO.
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 following setup: Gmail + me + masterpassword for the first one, Google Play + me + masterpassword for the second one, and Google Kids + kids + masterpassword. Another configuration could be: google + mail + pass, google + play + pass and google + kids + password. I actually would use my real login, since my accounts are already like this: email@example.com, firstname.lastname@example.org, email@example.com.
First there is nothing new to remember here, I already rememeber that I have 3 different accounts and what they are for.
Second, it doesn't matter how many accounts you have on a site or how many sites you can access with the same account.
You can use the url of a site and a different login for several accounts. You can use a description/purpose of your accounts and the same or different logins for several accounts on SSO services.
As I said, I don't see the problem.
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.
PS: the password for the demonstration gif is "passwordpassword"
- _prettyPrint calls into _getPasswordChar which will then take the character code modulo the length of the array of possible characters , 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 moved to KeeWeb since then + CPK for Chrome and Keepass2Android on my phone and couldn't be happier.
Your master password is 'passwordpassword'. 10 points if you know how I figured that out :)
Quite an interesting example of how easy it is to slip up and make something trivially crackable.
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?
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 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...)
As an ESL speaker myself, I wouldn't nitpick about grammar, though. The language on the site is very good in general, and learning second languages is very difficult. Je sais je ne peux ecriver francais bien. Right?
 - http://angel.net/~nic/passwd.current.html
 - https://github.com/marceloslacerda/password_generator
Mine doesn't have any provisions for passwords with a specific length or charset. If someone does not like what my pwget generates, I will adjust the password manually and write down the rules in a file that is kept in a private Git repo.
One thing though, LessPass sets HSTS headers, but should include the `includeSubDomains` directive and the `preload` directive to stop a first time MITM (for example, when you get a new phone). Once these are done, LessPass should be added to various browser preload lists.
How do I change a password without changing my master password?
That’s the purpose of the counter field in the options field set, increment it and you will get a new password.
Doesn't look like a win situation for me.
Much easier to just use a vault to store all this.
I did not market it so heavily. It has the same problems, most importantly rotation. As soon as you want to rotate one site's password the only option is to change the "master" password, but now you need to remember which site uses which master password, and your utility is gone. The random site requirements, as mentioned, is also a big deal.
(I can't use regular storage-based password managers, as I have ADD and I will lose my password file. If it is backed up, I will lose a backup, or I will forget to update it when passwords are changed, or something else. I always screw such things up, this is absolutely inevitable, so I have to prepare. To compensate, my symbolic memory is excellent, so I just chose to memorize all my passwords, as I can't lose my head. But even my memory has limits, and I had to lose some entropy on my passwords to keep them all in my head.)
Now, I will get the best of both worlds.
1) How do I change my master password? It appears that all generated passwords would change as well. Even master passwords should be expirable and changeable.
2) I don't just use a password manager to manage passwords. I use it to manage _credentials_. I have a ton of credentials, so I need something that will remember the _usernames_ for me as well. Otherwise I don't just have to memorize the master password - I also have to memorize the usernames for the hundreds of different logins I'm managing. That's a non-starter.
It seems they take info from the site (its name?) plus your master password and hash them - "LessPass uses PBKDF2 with 8192 iterations and a hash function sha-256."
I guess they then produce something of the required length and characters from the hash.
Guess it's ok till someone finds your master password.
It generates passwords based on a secret key ("seed") and memorized transformations to URLs. You can adapt that to use a master password, if you so desire, by using a password as a base for such a transformation, but that's not built in.
It syncs seamlessly across all desktop browsers, iOS and Android devices without any issues.
Works by using a master password and a keyword to generate a seed, then applies various deterministic algorithms to generate multiple passwords.
"The requirement for self-hosting is to have docker and docker-compose installed on your machine."
If I will trust this with my passwords, I need to know how to _really_ install it. I can't trust you if all you have to offer is a steaming pile of docker or your idea of how I should run my systems.
This is not a good idea.
it looks like anyone can try to brute force your password based on the login/site combo. can someone tell me why i'm wrong here?
i.e. I name hacker news hn or hack, as opposed to news.ycombinator.com - one more thing to guess for an attacker.
* if password hashes from any site you use leak and they’re weak, you’re compromised everywhere
* if any site is or becomes malicious and its operators/hackers read your password, you’re compromised everywhere
This approach (maybe not implementation – its hashing is kind of weak) is fine if your master password is strong enough, which it should be.
Not nearly good enough.
That blog post lists two extensions with hashing algorithm "custom" - that's SuperGenPass.
My current choice in software of this type is Twik (https://github.com/gustavomondron/twik) because it has an Android app available from F-Droid and an extension I can install in Chromium. The browser extension is especially good but not without faults. For daily use I find this adequate but I find myself in situations where I need to access a password outside of a browser or my phone which is a huge pain. Other drawbacks include no ability to change or bump the password to a new one without creating a new profile. Keeping my phone and computer in sync is also slightly annoying as you need to manually copy the UUID (long-ish complicated string) which is used to identify each profile.
I think a lot of these issues could be overcome by relatively simple solutions just by applying some sensible design without going all in and trying to be everything at once like LessPass is. If, for example, Twik generated QR codes for its profile keys which you could scan in the mobile app, it would speed things up massively. If it had a compatible CLI interface and a macOS menu bar application, it would be fantastic.
I'd also rather not bother with creating an account with another service just to sync my password version numbers and silly password rules that sites implement. The ability to self-host LessPass is nice but do I really need to bother with this? What's wrong with syncing this information in a simply formatted, maybe also encrypted, text file with services I already use such as Dropbox or Google Drive? Also, why is the default password length 12 characters? It's a small gripe but I thought the whole point of using software like this was to enforce good password practices.
I think https://getvau.lt/ gets pretty much everything right other than having to remember the rules of each password every time you generate it which, for me, isn't much better than remembering different strong passwords for multiple sites.
I've been hoping for some time that somebody would create a solution that I feel makes sense so I was excited to see this post but unfortunately it seems to have too many drawbacks for me personally to incorporate into my daily life. The open source nature of a lot of these products is very helpful and will hopefully reduce the effort I will have to eventually put into building a solution that gets out of my way.
Just so you know: SHA1 is problematic because of potential collision attacks. So you should definitely not use SHA1 for signing anything because it might be possible to construct a different document with the same signature. That's it.
What does it have to do with password derivation? Nothing at all. Collision attacks are irrelevant, what matters is computational complexity. So if you use PBKDF2-HMAC-SHA1 the only thing that would make your solution less secure is some shortcut allowing to compute a SHA1 hash radically faster without throwing faster hardware at it. And so far nobody found one.
Since you seem to like name calling, what do you call somebody making authoritative statements on matters they don't understand?
For reference, I am the author of Easy Passwords extension which uses a concept similar to LessPass. And it also uses SHA1 - for technical reasons.