LessPass: sync-less open source password manager | Hacker News Reader

LessPass: sync-less open source password manager

lesspass.com

412 pointsmgliwka234 comments

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.

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

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

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

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

Just sweeping them up en masse and trying popular keys.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But that's trivially mitigated - don't.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Slow is good for a password hashing function. :P

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

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

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

versus

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

My conclusion

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

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

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

No, dom0 is right.

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

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

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

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

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

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

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

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

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

A better comparison for this situation would be:

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

v.s.

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

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

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

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

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

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.

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

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

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

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

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

You are assuming that the site is not evil.

The site being evil is equivalent to the password being compromised.

And the password is the hash of the master password, which gives the evil all other passwords.

Additionally,

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

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

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

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

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

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

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

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

Came here to point out the same concerns, basically. I'll add this:

5. Its seems like there is no user-specific secret in addition to the master password. If two users happen to use the same master password (which is definitely a possibility, especially with weak or easily memorizable passwords) they will basically have all the same passwords for every site!

6. Rotating your passwords regularly, at least for your highly sensitive accounts, is very important. With this approach, you can't change any one of your passwords without changing the whole lot (i.e. changing your master password) which simply isn't practical.

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

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

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

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

[2]: https://padlock.io

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

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

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

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

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

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

> What is served over the web?

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

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

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

Not if the generated password also depends on your username.

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

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

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

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

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

If it's open source, how can you hope you achieve security through obscurity?

evil hax0r has database of leaked hashes from shittyonlinewebappyoudidntknowyousignedupfor.com, which includes your email address and a bad hash of your password. They run them through some standard password dictionaries using hashcat and break all of the 'letmein', 'monkey', 'qwerty', '111111' passwords within seconds. Then they run some bigger dictionaries and some nice rule-sets and crack another 50%. Then they start trying to crack the more difficult ones. GPUs come out and some fancy machine learning. Then they do some specialised stuff, like implementing the LessPass open source function to start trying to crack LessPass specific passwords. This is now as difficult to crack as your master password for LessPass, but it's "security through obscurity" because they have to guess that you use LessPass, and will probably only start attacking your password once all the low-hanging fruit is gone, giving you more time to change your password/ delete your affected account, etc.

As someone pointed out above, the problem with this argument is that the password becomes cipher text. That means that each time it is gathered by an attacker it gets easier to compromise. For most of us, this is not an issue because there is so much low hanging fruit. For some -- say a celebrity or person of public interest -- this could be a serious problem as they are already the target of a focused effort.

> That means that each time it is gathered by an attacker it gets easier to compromise.

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.

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"):

http://grisha.org/blog/2013/05/31/simple-solution-to-passwor...

Considering the part I quoted literally includes the phrase "based on a master password", you could probably have taken the time to 'figure out how it works' ;)

Lol - that's what happens when posting on a Monday before finishing the morning coffee.

Someone commented on my article then that you can pretty much accomplish this from the command line with:

    > echo "masterpassword gmail" | md5

(Ignoring the implication of the password potentially getting logged in shell history, of course.)

Maybe try just

> 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.

You better add a huge "do not use" warning to that blog post. Deriving passwords via SHA-512 or similar is a very common mistake and makes guessing your master password way too easy. I outlined the details in my blog post here:

https://palant.de/2016/04/20/security-considerations-for-pas...

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.

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.

[1] https://github.com/lesspass/lesspass

respectfully disagree.

"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.

But the page does show you the internals of what it does, it's just that it's done in a very high level, enough for the non-technical people who will most benefit from that page:

"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."

"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."

Etc.

I'm a technical person, and I thought this was a great and fast explanation to tell me what was going on. I don't need any more details than this and appreciated the brevity.

Well there are different levels of description here.

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.

> 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).

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.

Plain terms doesn't mean meanless terms. Having meaningless marketing buzzwords is not useful. You can explain things simply and clearly without resorting to vagueness.

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.

https://fossdroid.com/a/openkeychain.html https://fossdroid.com/a/password-store.html

I'm also a user of pass, but the fact that all the metadata is in clear is a big beef for me. How do you solve that, if at all?

Fellow pass user here.

freepass [0] seems like it could be a potential candidate, somewhere between pass and LessPass, but I haven't tried it out for myself yet.

[0]: https://github.com/myfreeweb/freepass

You could encrypt the password store folder with another gpg container. That would be your master password.

Maybe you can put the whole .pass directory inside an encfs directory.

Encryption all the way down.

You can use a hash of the site appended with a .pass wide pepper as the name of the directory storing credentials for a particular site, then use a wrapper script that hashes its input before passing it to pass.

Also full disk encryption.

This is all a lot of effort, if I went down that road I might as well skip "pass" and handle the passwords myself. What I like about pass is that there isn't much setup.

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.

Yes, under that threat model you would lose with all of these password managers.

How so? If the entire directory structure is also encrypted then no program can easily know which sites or services I have passwords for.

I was meaning if your machine was compromised.

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.

[0] https://github.com/lucaspiller/passosx

[1] https://github.com/davidjb/pass-ios

https://www.enpass.io/ is a winner for me.

>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

After lastpass was bought out, I went on a spree to find a different password manager and in that process, I tried almost all of them (free & paid). Nothing came close to Lastpass so I decided to stick with them until they mess up.

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)

Why were Lastpass and Dashlane better than 1Password for you?

I've used 1P for a few years without looking at the competition, so curious to hear what they can do.

I did try 1Password, and while it was pretty good, it was never "great". By that I mean,

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've tried all of them and Dashlane is by far my favorite and only one I was able to stick to using. Worth the money IMO.

I think you misunderstood my comment. I meant that there isn't anything comparable to 1Password's browser integration for pass (https://www.passwordstore.org/).

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

Pass doesn't have a sane iOS app. The only app available for Pass requires a jailbreak and doesn't function on phones without Cydia, GPG, and an SSH daemon running.

As an android user, I've tried 1password and it's pretty much the worst password experience on the platform. The Android client can't generate passwords, and it also can't cache my passphrase for any amount of time if I'm using the 1password keyboard (which is, as far as I can tell, the only way to make 1password fill a field.) After typing my fairly long passphrase 10x a day on the fiddly 1password keyboard with no feedback for the past few weeks, I'm switching to pass.

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.

> 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.

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?

>> 1Password also supports TOTP, so you don't need a seperate app for that - although for security you probably should.

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.

I've been using passff[0] with a lot of success for an in-browser pass client with filling support and so on. Works really well.

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.

[0] https://github.com/nwallace/passff

I have lost 4 hardware tokens already. :(

Not to shamelessly self promote, but if you like pass but hate GPG, then I already built you a command line password manager that is almost exactly the same as pass

It can securely save files, generate passwords, save passwords and optionally can sync using git.

https://github.com/ejcx/passgo

As someone with basically no experience with encryption, why would someone hate GPG?

GPG is well known to have a very clunky interface. It also is based on very old crypto (we know it works against the NSA, but we also know that it has problems that other crypto doesn't).

Eh, the UX doesn't look great compared to my current solution (KeePass). No browser integration or auto-type, no InputStick support on mobile, etc.

YubiKey support looks pretty nice though; I'm not sure there's an easy way to do what with KeePass.

Does it officially support every major browser on my desktop and phone? Anything that doesn't is still less useful to be than LastPass.

I don't think it supports any browsers via plugin. You use a separate app to unlock your keychain, it places the relevant password on your clipboard and then it clears the clipboard 30s later. Very simple and therefore avoids a whole bunch of vulnerabilities other password managers (like LastPass) introduce by integrating with browser plugins.

Sounds a lot more complicated than automatically logging me in without need for any action on my part like LastPass

Can you point me in the direction of the iOS client?

Nevermind, I think I've got it (https://github.com/davidjb/pass-ios) but is there a no-jailbreak option?

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.

I have written a similar Password manager as an UWP for Windows [0]. It didn't get much attention since i never tried to get some.

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.

[0] https://github.com/AndHell/CreatePass

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.

Very good point!

Also, some sites use a unified login which is shared between multiple sites owned by the same company. For example, StackOverflow uses an account which is shared across all the various StackExchange-type sites, and Gamepedia requires you to sign in with your "Curse Community Account". (I'm sure there are more examples; those are just the ones off the top of my head.)

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.

Also, most people need help sooner or later, and they can't call IT for help with a system like this. Either they remember all the needed information or they don't.

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...

It's important to change your passwords at regular intervals, even if you use a secure one.

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!

There's also some privacy and UX concerns with client certs. See http://www.browserauth.net/tls-client-authentication

Personally I'd love to see UAF or SQRL take off. Lots of potential there.

most browsers will auto select the right cert. But for browsers that dont support the keygen tag you have to create the cert including priv key and pw. you can of course create many certs for different users, you can of course also sign them yourself, no ca is needed besides for the ssl server cert. most of the points on that site is moot besides poor support on some browsers.

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

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.

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 think there is where the connected version can play an important role. From my understanding it stores everything but the password, so that can keep track of password rules, counters, etc per site.

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.

State for password managers is almost always stored encrypted, i.e. in a form useless to the attacker.

> But if you have storage for the special cases, why not just store the passwords to begin with?

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).

#1 is true too for an encrypted password database.

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.

The problem with writing passwords down is that I need to fly places and it's not unheard of if you work in financial tech or military tech to have your things riffled through at the boarder. Plus a mugger can say "give me your things!" or "Empty your pockets!" and now he has my credentials.

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 used any stateful password manager instead of a piece of paper, then the passwords would be stored in an encrypted fashion. Don't give out your master password and your passwords are useless to an attacker.

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.

> 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?

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!

I'm the creator of LessPass. We did not expect as many visits on our website. Thank you. We are working on:

* 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.

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:

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.

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.

LessPass starts with 8192 iterations. I prepare the code to increase this number, I will not let users change it. We are creating an interface to change master password and then we will plan a LessPass version change (with a number of iterations changes)

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.

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?

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.

https://github.com/lesspass/lesspass/blob/master/lesspass.sh...

The SECRET_KEY is used by Django, see here: https://stackoverflow.com/questions/7382149/django-secret-ke...

EDIT: I've created a issue on GitHub about this. (https://github.com/lesspass/lesspass/issues/43)

I always wondered why people resorted to `date(1)` when there's `random(4)`:

    $ xxd -l 20 -p /dev/random
    669d8372d63897e37776d05dc8acccbacf26befc

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.

> Why not provide people with a quick and easy "login by email", since this fallback is almost always available anyway?

There was Mozilla's Persona (which was shut down a few days ago). Now there is this:

https://portier.github.io/

Not-so-good good idea?

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 could just put the Algorithm or the version into the configuration. That would at least allow a gradual migration.

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.

Isn't that what the hosted profile is for?

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.

It's also really shocking to see just how many accounts the average person amasses. My KWallet had some 250 entries at peak times.

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.

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.

[0] https://pwdhash.com/

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)

Okay, but now I have to remember 3x as many things as with a managed password manager. And how do I handle having multiple accounts on the same website?

"You can put whatever you want in field X" is not a solution to the problem IMO.

> how do I handle having multiple accounts on the same website?

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: username.mail@gmail.com, username.play@gmail.com, username.kids@gmail.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.

> You use the url of the site and your different logins to generate different passwords. What's so difficult about it.

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.

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"

@dragondave on github open an issue https://github.com/lesspass/lesspass/issues/48. We are working on it.

This is why I designed the similarly-updating glyphs in surpass (https://stuartpb.github.io/surpass/demo.html) to only update after a half-second delay when masked.

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".

[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...

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.

Hi Guillaume,

Your master password is 'passwordpassword'. 10 points if you know how I figured that out :)

An issue was raised for this over on GitHub[1] after it was pointed out by others.

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

What happens when the method of creating passwords needs updating, do I then need to visit countless numbers of sites to change the password?

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?

We are not a danger to LastPass. We'll see in time if it happens. The idea came after using KeePass -> I want to keep less passwords -> lesspass -> lesspass.com is available -> done

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.

Actually, you can. See https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4...

That is either by using the "connected version" or loosing the multi devices ability. BTW shouldn't the "connected version" be the one detailed on the home page? Sure sounds more attractive to me.

Or you have to remember the counter. Since most people just append a counter to their password for those sites that force them to change regularly, it's not really that different. :)

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...)

https://chrome.google.com/webstore/detail/alzheimer-password...

https://github.com/viralpoetry/password-generator

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.

A gentle critique: don't use "How it works?" since that is not proper English. "How does it work?" is better.

On what grounds is it not "proper English"?

http://ell.stackexchange.com/questions/17778/how-it-works-vs...

"How it works" without the question mark is fine, too. The site actually uses "How it works ?" which is a dead giveaway that the author is French.

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?

I guess my comma use is also a dead giveaway of my first language...

Yes, I should have added that "How it works" sans question mark is proper as well.

I started using Nic Wolff's password generator[0] to solve that very problem, but I noticed that the need for connected passwords makes up a large size of the passwords that I needed to use, so I gave up on the idea of "store nothing passwords". The idea of generating always the same password for the same site is also doesn't work, because of database breaches, so in the end I created a program[1] that did all the things I needed. Check the README to know how it works.

[0] - http://angel.net/~nic/passwd.current.html

[1] - https://github.com/marceloslacerda/password_generator

Looks pretty similar to what I'm using: https://github.com/majewsky/pwget

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.

Very cool project!

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.

What happens if a site requires you to change passwords regularly and keeps a history of the passwords you've used? Wouldn't you be locked on a single password for each site (or a very limited number of options to force the app to change it)

I guess you can increment the password length by one each time. Though you have to keep track of the last used length.

For brain dead sites with rules like "min 6 chars, max 8, mandatory change every 60 days", that won't take you very far.

So you're changing remembering 1 password for each site, for remembering a bunch of option configurations for each site.

Doesn't look like a win situation for me.

From the FAQ:

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.

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

Does your work predate Stanford PwdHash?

https://crypto.stanford.edu/PwdHash/

Maybe! archive.org's oldest capture of my page [0] is from 22 Dec 03, and doesn't have anything for Stanford's until 9 Apr 04 [1]. But I don't think they got the idea from me, since the first links to my page from blogs and aggregators came in Sep 04 after I added the bookmarklet [2].

[0] https://web.archive.org/web/20031222201145/http://angel.net/...

[1] https://web.archive.org/web/20040507195550/http://crypto.sta...

[2] http://jonudell.net/udell/2004-09-07-nic-wolffs-single-signo...

I used to use SuperGenPass[1] to do exactly this, but what you'll soon find is that every website has slightly different password rules, so you'll have to start memorizing unique settings for each site (i.e. website X can't have certain chars, website Y can't be longer than 12 chars, etc...). Then you run into the issue of multiple things you need to remember, such as secret answers for various questions, birthdays that you may lie about, etc...

Much easier to just use a vault to store all this.

[1] https://chriszarate.github.io/supergenpass/mobile/

I did roughly the same thing twelve years ago, with even less security built in (hey, I was young(er)):

https://bookmarklets.arantius.com/password+maker+bookmarklet

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.

OK, fine. This is one thing I can finally use.

(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.

What's wrong with something like Lastpass?

Lastpass is something I have no control of. Leaks can happen (already have: https://blog.lastpass.com/2015/06/lastpass-security-notice.h...). More importantly, DDoS can happen, and I will be out of access to everything.

Lastpass stores your password encrypted. If in your threat model you're unwilling to use Lastpass because of the leakability of the master database, you should avoid Lesspass since trying to guess your password on Webstie X given Lastpass database is more/less the same as trying to guess it given you're using Lesspass.

Like I said before, leakability of master database is not that big concern. DDoS on Lastpass, however, is a very likely scenario, especially in the light of recent high-profile DDoS attacks.

DDoS on LastPass is not a big deal as long as you have at least one device logged on. LastPass database is stored locally and can be used off-line.

Aside from the security concerns already noted I have two major questions:

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.

How it works roughly: https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4...

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.

I use [pass](https://www.passwordstore.org/) which is an open source command line password manager. It uses gpg to encrypt passwords which in turn is setup to use a hardware key with its own password. The downside is the metadata which is exposed in file system tree, however the data is stored on a dm-crypted disk. Difficult to setup but much more secure.

Enpass is my goto, recently recommended it to some people as well and all are happy. I have it on my phone as well as work PC, personal laptop and a linux box. One master password and it's all local, I just use dropbox to sync the encrypted "wallet" so I have my accounts on all my devices. https://www.enpass.io/