Also it requires you to remember usernames or email addresses used at each website. For the last 8+ years I've been using unique usernames and emails at each website. I also have to deal with a number of systems that require me to change passwords every 3 months and I don't want to also be remembering dates.

I can't remember what the crisis was but it was after Ashley Madison and there had been a series of password databases put up on tor. And also there were some things about people getting harassed across platforms. It happened right before I moved to a new state and when I set up all my new utilities and banking and etc I used a password manager and created unique username flavors. Like fluidcruft253b for water and fluidcruftAdaG for gas and fluidcruft563d for banking etc.

> Also it requires you to remember usernames or email addresses used at each website. For the last 8+ years I've been using unique usernames and emails at each website. I also have to deal with a number of systems that require me to change passwords every 3 months and I don't want to also be remembering dates.

Interesting idea, but that seems like overkill to me.

Like, yeah, if I was to sign up for Ashley Madison, it would be ideal for me to use an email that is not my known one. ;) But in most cases I don't think that's adding much extra security. If anything, you're more likely to lose access to a site by forgetting what your super secret email for it was than from someone hacking it.

This isn't to say that I'm totally against it. Part of me just feels like there's more that can go wrong doing it that way.

Those of us using a different random username and/or email address for each sender do it for two reasons:

1. If whichever identifier is used for login (eg. email address) is exposed/leaked, it cannot be used by the attacker to lookup accounts in other leak dumps.

2. It allows to detect which site/service/entity is selling or leaking email addresses to third parties which send spam. I no longer need or have a spam folder. The moment I receive a spam email from someone I don't recognize, I can lookup which site/service that email was for, and choose how to act; eg. update that site/service's to use a new email address and blackhole the old one; maybe unsubscribe/close the offending account if it happens again. Of course since setting up my unique-email-per-site setup, I haven't been victim to third-party spam yet; likely because I no longer have a personal email in public Github commits.

> If anything, you're more likely to lose access to a site by forgetting what your super secret email for it was than from someone hacking it.

With a full-featured password manager it's only a matter of backups and remembering your master password. You don't worry about forgetting anything after that's covered.

I think there were also a bunch of social engineering things going on at the time. Things like calling up support and not knowing the password but combining info from different sites and username and email were enough to talk support into doing dumb things. Some of the dumps include things like "First pet's name" and all the common insecurity questions.

- LessPass is a webpage that can be changed at any time and collect website, username and password triplets.

This is quite a big issue because it can be used for targeted attacks. There is no way of detecting compromises without reading the source on every page load.

In all fairness, it's trivial to host it yourself.

There is no way you can tell if there’s an undetectable worm in your system.

Those things are in no way comparable.

First of all, this is not a transfer of trust from A to B: in both cases (traditional password manager or this thing) you still need to trust that your own device is not compromised. But with this thing, you _also_ need to trust that the website is not compromised.

Secondly, the website is a much juicier attack target than your personal computer.

If you choose a strong master key this should still be secure even if a site leaks a generated sub-key/password. All you need to do is change the sub-key for that site. Both this and password managers though still can be hosed if the machine your using is compromised. Otherwise it should be secure as your master key.

Leaked passwords can be changed for this they have what looks like a version input. If the master key can be reversed from a cryptographic hash function either the hash function has been broken or you chose a really bad master key.

Although storing PINs and all the other random things some sites may use is a valid point. I am not sure I would call this less secure than a traditional password manager though.

You make some reasonable points, but two I find somewhat strange:

> Setting the master password to something insecure will undermine the security of all derived passwords

Then don't do that. The question is: Is LessPass in practice more likely to encourage this kind of poor security than its alternatives?

> Master key is related to the generated passwords. Using a strong PBKDF this should not be a problem, but why take the risk?

If its PBKDF is broken then so is its security. If crypto is incorrectly implemented in any other password manager then it too is broken. If the crypto algorithms used by TLS are broken then our online banking is broken. We don't avoid other things that rely on crypto just in case they might get broken some day.

[Mods: accidentally posted this as a top-level reply rather than a reply to this comment, sorry!]

> - Leaked passwords cannot be changed.

What's funny is I nearly just finished making a Node.js library that does what Lesspass does, and it addresses this one point.

Basically, I added a concept of an `nonce` property, which is just a number that gets incremented every time a password for a service has to change. (not sure if nonce is the correct term)

I figure that if I forget a password, I can just keep adding 1 to the nonce until it generates the current password.

Here's a gist of it: https://gist.github.com/Ravenstine/8053651dd2aeacee9973b9f93...

I haven't used it anywhere, so if there's a serious flaw don't believe you're going to access my bank account. lol

EDIT: It looks like Lesspass also uses a counter property. Kinda amazed that two people independently arrived at such a similar idea. :)

>Basically, I added a concept of an `nonce` property, which is just a number that gets incremented every time a password for a service has to change.

So your solution to issues with stateless password managers is to... add state?

In a sense, but not state that gets stored anywhere. The "state" that's being mentioned in this thread is referring to storing state in some kind of database. My idea was to not require storage of state outside of the human mind, and to make any state easily guessable(by the owner) through exhaustive search.

Even Lesspass uses an incremented number for that purpose, from what I can tell. So it adds state in the sense that you're talking about.

> It looks like Lesspass also uses a counter property. Kinda amazed that two people independently arrived at such a similar idea. :)

The system I made "sinkless" https://github.com/kybernetikos/sinkless does the same thing. Its a pretty obvious solution to the problem of needing to able to change passwords, and it also solves situations where sites have crazy extra restrictions that can't be reduced to just the alphabet. My system also shows you emojis so you know when you've got your password and site settings right.

Most of the other complaints are also over blown, but the lack of 2fa is a genuine loss.

I had a similar intent for less important accounts (I would keep using a more secure but less convenient solution for more significant credentials). To shortcut guessing the index you could store just the site plus index in a cookie or similar - if that data is lost you can still use the guesswork option. If tracking is a concern so you don't want site names to be stored, has the site name and index and use that to build a bloom filter (not perfect, but it will usually guess right without storing the actual data). Though for my use I wouldn't care that the site names were known.

Another similar idea to stop people using the "just add a character or increment a number" method for dealing with passwords that need to be changed monthly. The password is based upon a hash of master+site+year+month+salt. You are still compromised if the master password is compromised, it is never any worse than what people do already. Again I'd not use this sort of thing for truly important accounts.

> Kinda amazed that two people independently arrived at such a similar idea. :)

I've seen many similar schemes, some identical to those I've considered and either dismissed of not found time to think through, some with minor variations. I think this is a problem a lot of people encounter so it is a common though-game, so I'm not surprised that for every combination of tricks there are a number of people who have thought the same (or even got around to implementing something).

that would be an epoch, not a nonce. it’s still awful