
Lesspass – open-source stateless password manager - thrwaway69
https://lesspass.com/
======
igammarays
I honestly am baffled how such a bad idea which is objectively less secure (no
2FA) and less convenient (changing a master password is a pain) than a
password manager is getting so much attention (2000+ stars on Github, WTF!?).

~~~
Dinux
We've seen many of these tools and they are all flawed in the same way.

\- Setting the master password to something insecure will undermine the
security of all derived passwords. The same thing can be said for traditional
password managers but they at least do not correlate the master password to
all other service passwords.

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

\- Leaked passwords cannot be changed.

\- There are enough services which generate you a password and then only later
lets you change it.

\- Cannot store PIN, ID, CVV, files etc.

~~~
ravenstine
> \- 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...](https://gist.github.com/Ravenstine/8053651dd2aeacee9973b9f93a892311)

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

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

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

------
minitech
[https://github.com/lesspass/lesspass/blob/e134350f2b17b63a3a...](https://github.com/lesspass/lesspass/blob/e134350f2b17b63a3a6d53f762ee592743c1d256/cli/lesspass/password.py):

    
    
        salt = (
            password_profile["site"]
            + password_profile["login"]
            + hex(password_profile["counter"])[2:]
        )
    

It’s not ideal for “myusername” on “example.co”, “yusername” on “example.com”,
and “yusernam” on “example.com” with counter 225 to produce the same password.
Maybe it never affects anyone, but it’s so easily avoided there’s no reason to
make this a hazard.

`_insert_string_pseudo_randomly` seems overcomplicated compared to just
putting `string` at the end, too.

------
Mave83
I don't know, but syncing was never a problem for by tools. Use bitwarden,
lastpass or some other available, good working tools and don't waste your time
like that

~~~
aloknnikhil
+1 for Bitwarden, if you have to go the open-source/self-hosted route.

~~~
cies
I'm also a fan of Bitwarden. It's e2e encrypted, so they never get to see yr
password. The Browser plugins are opensource and an open source server impl
exists (but since it's e2e is not essential for security).

------
kuon
While this is nice in theory, it lacks the following I use: usernames, TOTP,
credit cards, attachments (like scanned 2FA number grid some banks use),
history, autofill. And how does changing master password works?

~~~
laumars
TOTP should NOT be stored with your passwords. I know some password managers
give this option for convenience but the point of TOTP is it’s something you
have (traditionally a physical device) that’s separate from something you know
(a password). When both of those things are stored on the same place then it
effectively just becomes multiple inputs for 1FA.

~~~
hkt
This just means the poster above doesn't consider a compromise of their
password manager a risk. It remains 2FA because the key material for the OTP
does not leave the password manager, whereas the password travels down the
wire. For a start, this makes it hard to brute force the account for even an
inept provider.

~~~
kuon
I also have 2 db (KeepassXC), I have my low security db (like games, online
stores, forums...) and my high security db (like AWS credentials...), the
second one requires a hardware key for unlocking.

But some websites (like some games) in the first category have mandatory 2FA.

------
chii
a much easier way to not have to remember a password is to reset your password
every time using the 'forgot password' feature available for most sites.

You generate a new, random password for that, but you don't remember, nor
store it. You just use the forgot-password feature next time you login.

This way, you just need to secure your email provider's password (say, gmail
is pretty good - 2-factor and they constantly check for weird logins).

~~~
harikb
Oh my! You really do this? Most sites these days ask Security questions and it
is no longer a single click from email.

In addition, certain sites log you out after the change-password action and
require you to explicitly login right after.

Explicitly not storing the password sounds.. brave? stupid?

~~~
chii
> Most sites these days ask Security questions and it is no longer a single
> click from email.

yes, i noticed. especially apple itunes/icloud. I hate them. And i consciously
choose to avoid sites like these.

I prefer sites that mail you a one time token to reset your password (and also
log you in automatically). Or you can just copy the password once, and do the
login for that one session.

------
jan6
weird, how everybody has a negative sentiment, but also doesn't consider not
using the fields as the labels indicate... and ALSO thinks this 8s an "online"
thingy for some reason...(it just has a javascript version, just like it has a
python version)

you don't need a full username or email at the "user" field, can just use
gmail@alice or JohnDoe-bank.com and whatnot, similarly with the "site"
field... can also cut them all off, say, skip the first, or last character...

you don't need the same master password... but more than that, you don't need
to start at counter ONE... you might start at counter len(domain) or
len(name), for example...

IF you have 1000+ passwords, by all means, use a traditional manager... but
this is perfect for people with less passwords, no sync needed if you don't
want to, your passwords file cannot get lost or stolen, etc...

------
igammarays
This is such a bad idea. Now you have to remember the counter field and
username you used for each site. Also you can’t change your master password
without changing every single item in your vault. As a person with 1000+
passwords, this would never work.

~~~
hannasanarion
And the fact that your passwords are deterministic means that somebody who has
one of your passwords can learn the master from it and pwn you everywhere.

Some non-secure login forms do still exist. Boardgamecore is one of them
(shame away, the webmaster seems to think it's too expensive to get a cert and
I can't talk sense into him). The whole internet knows my boardgamecore
password.

I don't care too much though, because I use LastPass and that password is
random. The worst you can do with it is make a bad move in my chess game. The
fact that my board game password is public doesn't endanger any of my other
security. My master password is still entirely out of reach.

But if I was using LessPass, you could use rapid offline cracking to derive my
master password from my boardgamecore password. If you get lucky or if my
master isn't strong enough, in short order you have my email and my bank and
hundreds of other things, which I have to go change manually one by one after
I figure out how to deal with the fact that all my money's gone.

With a deterministic password system, if somebody pwns you somewhere, they've
pwnd you everywhere. It is only mildly better than reusing the same password
everywhere. The danger of so many points of failure and no failsafety is
definitely not worth the theoretical purity of "statelessness" (which you
don't even really have because the state is in your head or a Google sheet)

~~~
Moru
Your bank allows you to move money with just a password? Change to some bank
where you get a way of logging in that requires some sort of certs. Ours used
to have a small box you had to enter a key that the website provided to you,
plus your pincode. Now there is an app that displays where you are logging in
and you have to enter your pin to sign. When you transfer money it needs
another signature and you can see all the transactions on the same screen
before you hit enter.

~~~
hannasanarion
Actually all you need to move money is an account and routing number. In US
banks, that's all you need for an ACH pull. No password, no pin, no nothing.
Learned that the hard way when a friend accidentally stole $5000 from me
because he thought my account number was his.

~~~
tialaramex
But presumably you can just unwind that? In the UK the "Direct Debit
guarantee" paperwork that's included with every form where you give people
your account details explains that the bank promises to unwind any
transactions that you decide you didn't want.

Direct Debit also only works if you're an accredited recipient, because
obviously under guarantee the bank is going to want to claw back that money it
just refunded and so they need to know the recipient can afford that almost
always. The huge global utility company won't go bankrupt if I unwind a
monthly utility bill payment, but the fly-by-night vape shop might. Presumably
ACH pull is the same?

------
princevegeta89
Seemed like a good idea at first, but I can quickly think of many
shortcomings:

I wouldn't know wtf my password is. And in case a login to one of my sites
fails, I wouldn't be able to manually copy paste the password and go step by
step?

What if the domain name of the site changed? How is it supposed to work with
mobile versions like m.Facebook.com?

Or how would it work with apps? Is there a way to tell a login applies to
multiple sites?

I'd be stuck in this stateless non-transparent world without knowing wtf is
going on I guess. And not to mention I cannot maintain things like notes/cc
info etc.

------
searchableguy
What I learned from this thread: even engineers use insecure vaults with
repeatable, deterministic, and exploitable passwords.

Are there any non deterministic unique passwordless way to login without
depending on any entity?

Can you use your blood or state of the body to login? Each time you login,
there will be some differences but not enough that you could not match
similarity. It will adapt every time you login and forget about past states.

Over a long duration without logging in, your blood or state could be much
different so there is no chance of forever having lost your login if something
is compromised.

~~~
ThePhysicist
There’s the concept of unclonable physical functions (PUFs)
([https://en.m.wikipedia.org/wiki/Physical_unclonable_function](https://en.m.wikipedia.org/wiki/Physical_unclonable_function))
that can provide something like this. Some companies like Physec offer key
derivation mechanisms based on PUFs that depend on the physical
characteristics of the environment of the device that generates the key (e.g.
the electromagnetic impedance), so an attacker needs the actual device to
produce a key that matches the profile, and tampering with the device by e.g.
opening it destroys its ability to generate a key due to changes in impedance.

It’s a really neat concept but I don’t think anyone found a way to apply it to
a human, though it should be possible (e.g. using your heartbeat).

~~~
nikola1010
A company called nymi does exactly this. They have a wrist-watch device that
actively profiles wearer's heartbeat for unique identification.

------
TedDoesntTalk
There is nothing new under the sun. This was done 15 years ago by
[http://passwordmaker.org](http://passwordmaker.org) and the older site
[http://passwordmaker.sourceforge.net/](http://passwordmaker.sourceforge.net/)

LessPass even stole the "one password to rule them all" phrase and the idea of
"profiles"

There are still many active ports of ports of PasswordMaker:

[https://www.google.com/search?q=github+passwordmaker&oq=gith...](https://www.google.com/search?q=github+passwordmaker&oq=github+passwordmaker)

Heres the original web version:

[https://passwordmaker.org/passwordmaker.html](https://passwordmaker.org/passwordmaker.html)

~~~
hrdwdmrbl
I used to use another one,
[https://chriszarate.github.io/supergenpass/](https://chriszarate.github.io/supergenpass/)

~~~
riedel
I am quite happy with
[https://crypto.stanford.edu/PwdHash/](https://crypto.stanford.edu/PwdHash/)

Funnily different master passwords generate a different output space ( good if
you want special characters), which is a tiny bit worrying.

~~~
tonetheman
I have used this one for a long time too

------
Ghjklov
Looks a lot like [https://masterpassword.app/](https://masterpassword.app/)
which is what I use and describe as more of a password calculator.

~~~
swaits
I’ve used this too, and for quite a long time. Very happy with it. State can
be synchronized, which makes it easy to use across multiple devices.

I switched to this from my own algorithm which I mentioned here about a decade
ago.
[https://news.ycombinator.com/item?id=2431480](https://news.ycombinator.com/item?id=2431480)

~~~
annolir
I'm using something kinda similar to this :) Pre-programmed my YubiKeys with a
'master password' in a safe environment, and using their HMAC signing
capability to generate consistent passwords, kinda similar to your algorithm.
This makes sure the master password is safe, and that passwords can only be
generated one at a time when I press the YubiKey.
[https://github.com/noliran/ykpass](https://github.com/noliran/ykpass)

------
system2
Why can't people use keepass in local environment, or store the database in
sftp? Why do people try so hard to use "cloud" based clearly unsecure
solutions?

~~~
dingo_bat
> Why can't people use keepass in local environment

How do I use it on my phone then?

> or store the database in sftp

SFTP where? The "cloud"?

> Why do people try so hard to use "cloud" based clearly unsecure solutions?

Because it is the easiest and most convenient and most useful.

~~~
fbnlsr
Trying to use Keepass on my phone is the exact reason I had to find another
solution.

I've switched to Bitwarden a few months ago, and I couldn't be happier.

~~~
ahnick
As a Keepass(keepassxc on Ubuntu) user I recently switched to Strongbox from
the now abandoned MiniKeePass, which I have been very happy with. It supports
using FaceID with a Pin, which is great for quick access on my phone. Syncing
with wireguard/resilio sync.

------
anfilt
Assuming your master key/password is strong this system is still secure if one
the sites you use leak the generated password. However, if you somehow leak
your master key then all your accounts are exposed.

It's weakness mainly is if the machine you use is compromised so are your
passwords. However, the same applies to a password manager. Unless you use an
offline system to generate these sub-keys.

------
cyphar
It's a bit of a cheat to argue this is stateless, given that the profiles
(which stateful pieces of information which contain information about password
complexity rules for each site, as well as which version of the password
you're using) are synchronised with an online service. It is nice that you can
self-host it though.

While I do applaud the idea (synchronising password databases manually is
definitely something that gets on my nerves -- I use KeepassXC), I think the
benefit of having completely random passwords that have no connection with
each other is much higher. With systems like this, you have to have very
strong confidence that your master password is very strong and will never be
discovered. But with a file-based system, even if your master password is weak
or compromised an attacker still needs to get an up-to-date version of your
password file.

I'm also pretty sure I've seen this idea implemented a few times over the
years (it's not clear to me if this is a new project or a reposting of an
older project).

------
smsm42
Wait, so if somebody learns my master password somehow, they automatically get
access to _every_ website I've registered in, without even needing to steal my
database and such? Not sure that's a good idea.

~~~
baobabKoodaa
I solved this problem in my deterministic password manager: passwords are
generated from a keyfile, which is encrypted with your master password. This
means that if someone gains access to your master password, they can't do
anything without the keyfile, and likewise if someone gets access to the
keyfile without the master password. Also, changing the master password
becomes a simple operation (the keyfile is simply re-encrypted, no need to
change site passwords). Since passwords are generated deterministically, the
keyfile needs to be synced only once to all devices, after that you have
syncless operation.
[https://github.com/baobabKoodaa/baopass](https://github.com/baobabKoodaa/baopass)

~~~
DagAgren
Why bother with the encryption? All you need to do is put random data in the
keyfile, and combine the master key and keyfile data to create your key.

~~~
baobabKoodaa
Encryption allows you to change the master password without forcing you to
change all site passwords. To illustrate:

Scenario A: keyfile is encrypted with master password, site passwords are
generated from plaintext keyfile. If the master password needs to be changed,
the keyfile is simply encrypted again. The plaintext keyfile remains the same,
which means all generated passwords remain the same. No need to change site
passwords.

Scenario B: keyfile is not encrypted, both keyfile and master password are
used as inputs to generate passwords. In this scenario, any change to the
master password causes all generated passwords to change. This would obviously
be undesirable.

------
dheera
My almost* stateless password manager:

[https://github.com/dheera/scripts/blob/master/passgen](https://github.com/dheera/scripts/blob/master/passgen)
(generates passwords)

[https://github.com/dheera/scripts/blob/master/passenter](https://github.com/dheera/scripts/blob/master/passenter)
(generates and types them in with a 3 second delay to switch windows)

It uses PBKDF2-HMAC-SHA256 on a master password concatenated with the domain
of the service you need a password for.

*It only requires storing information about per-domain idiotic password requirements (min length, max length, require symbol, etc.) and the Nth password you use on the site.

------
hkt
I honestly wouldn't want to have to change my master password to change a
specific password on a site. It's a neat idea but not one I'd use in practice.

In practice I use this:
[https://www.passwordstore.org/](https://www.passwordstore.org/)

It has a great command line interface, is simple to audit, levers gpg for
encryption and git for synchronisation, and has browser extensions and apps
for android etc too. It even has an extension for OTP.

I've even gone to the length of using it in scripts to inject secrets: "pass
buildsecret" will yield the right string. With a thin wrapper that can be
supplied to ansible, or terraform, or whatever. It's great. Plus, I can change
passwords arbitrarily.

~~~
tialaramex
Pass is great, but it's a very niche piece of software. I was actually
surprised (but grateful) that it existed because so many people have a GUI
password manager.

I have the Firefox integration (and I contributed to that integration) and
like that much better than other software I tried in this space, not least
because I understand all the moving parts so if they break I'm not helpless.

I actually did use the Stanford PwdHash linked above on some systems precisely
because password managers were so unsatisfactory. But it's clearly true that
if any solution in that class were significantly popular it begins to make
sense for bad guys to attack that specifically - assume the gibberish in
stolen plaintext passwords is actually output from a "stateless" scheme like
this and brute force it. Once you decide to compensate for that (e.g. maybe
you're going to have a 12 random character master password entered every time
you log in somewhere) password management seems like the less awful option.

I'd like to see low value sites that this sort of thing is clearly most suited
for (so like Hacker News, or Stack Overflow, not your bank) offering WebAuthn
with no password. Blip, you're in. Very safe, but also very low friction.

------
aabbcc1241
I made something similar back in 2018. Initially started as a bash script,
later on added web version so I can use it from mobile devices.

It let you reduce the generated password length so it can satisfy the
"security requirements" of some sites... I suspect those sites are storing
plain text password in a SQL table column, otherwise why would it limit the
length to not excess 12 or 20 words?...

I shared it to some peers but they just prefer to use password they can
remember by their brain ....

[https://github.com/beenotung/gpw](https://github.com/beenotung/gpw)

~~~
aabbcc1241
The version posted by the OP seems started from 2016.

------
thinkloop
> Sometimes sites have specific password rules. For instance, some banks only
> accept passwords made of numbers.

An easy solution would be to append "A1!" to all generated passwords.

> You also can self host your LessPass Database

From a local stateless solution to managing a server, that escalated fast.

~~~
vntok
> For instance, some banks only accept passwords made of numbers.

> An easy solution would be to append "A1!" to all generated passwords.

Your easy solution does not even work on the example _you_ picked on.

~~~
thinkloop
Lol, you're right, misread that

------
kissgyorgy
The counter for password change is a great idea! I was aware of this
limitation of stateless password managers and I always looking for how they
solve the change password problem. Nobody solved it so far, this is the first
I saw. Good job!

~~~
baobabKoodaa
All previous deterministic password managers could also be used with a
counter: instead of inputting site "hackernews" you would input site
"hackernews2" etc...

------
nicwolff
Jeez, I probably invented using Javascript to generate site passwords by
hashing the domain with a master password (see e.g.
[https://books.google.com/books?id=4jYEAAAAMBAJ&pg=PA34](https://books.google.com/books?id=4jYEAAAAMBAJ&pg=PA34))
– and I certainly don't use it any more!

[http://www.angel.net/~nic/passwd.current.html](http://www.angel.net/~nic/passwd.current.html)

------
StavrosK
I used this (or a variation of this) for years. In the end, its inability to
handle changed passwords was its downfall. If your bank doesn't let you use
the specific password this generates because of some random stupid rule ("your
password can't contain two numbers in a row"), you're out of luck, there's no
way to generate a compliant password without remembering either a completely
different master pass or that the counter for that site is now set to
2/3/whatever.

I switched to BitWarden and am much happier now.

------
retonom
I also found that having one master password like that is probably not so
clever. But who is saying that you have to use the three input fields like
this? I came up with my own system. So I'm kind of using lesspass now as a
password generator. The generated password I save in keepassxc along with the
rest of the information. In most cases I don't need to consult the vault and
can generate the password on the fly but I'm not bound to lesspass at all. So
in case I should lose access to the vault I can still log into most sites.

~~~
igammarays
In other words, this is a backup. But you could, you know, just backup your
vault.

~~~
retonom
not it's not just a backup. I backup my vault of course.

it's:

1\. a way to access most of my passwords from everywhere even when I don't
have access to the vault 2\. a way to access most of my passwords even when
all of my vault copies and backups are destroyed

------
chromatin
I like that it is deterministic, and I was going to ask what if a single
password was compromised, but it looks like there is a "counter" field for
each site that overcomes this. Nicely done.

~~~
arkadiyt
Imagine your hundreds of accounts and having to somehow remember which site
uses which version/counter of a password.

------
NelsonMinar
I used to use a system like this for passwords. The downfall is it depends on
the site name being exactly right. For instance a naive program will treat
example.com and login.example.com as different sites with different passwords,
which is a real problem in practice. You can work around this but ultimately
it means the user has to keep some state in mind, which is "the real site name
for this site that I used to generate the password". I was surprised what a
pain that was back when I did this.

------
bythckr
Amit from [https://www.labnol.org/](https://www.labnol.org/) has had a similar
tool for 6 years -
[https://github.com/labnol/passwords](https://github.com/labnol/passwords)

~~~
rkeene2
[https://webpass.rkeene.org/](https://webpass.rkeene.org/) is also similar,
but a single JavaScript file which you can host yourself. It also supports
syncing, but for this it needs to reach out to a server. It doesn't store the
data on the server, though, just passed it through to another online host.

------
CraftThatBlock
Created something similar using the Masterpassword protocol:
[https://masterpassx.org](https://masterpassx.org)

(Also open-source:
[https://github.com/Cretezy/MasterPassX](https://github.com/Cretezy/MasterPassX))

------
gbasin
This seems similar to how crypto wallets are often generated -- with a seed
phrase. Exposing that master password regularly seems dangerous -- if it leaks
once, you're screwed. Hence why crypto wallet seed phrases are (supposed to
be) carefully secured offline.

------
indutny
You can still sync encrypted website names and logins, and in fact you have to
if you ever plan to change the passwords on the websites.

As a shameless plug: [https://derivepass.com/](https://derivepass.com/)

------
slaymaker1907
I wrote a similar utility but using scrypt a while back
[https://slaymaker1907.github.io/password/](https://slaymaker1907.github.io/password/).

------
diablo1
Just so people know, if you have to change a pass with Lesspass, because a
site/service got breached, you can simply increment the password up by one to
get a new 'hash'

------
TrueNomad
is it just me or is this just off-loading the same password use on many sites
on to an algorithm. After all, your username is quasi-public info and the site
can not even be called quasi. It is fully public. Few options will not make it
unique enough that it can notbe broken. After all, the only thing that the
nefarious person needs is your master password and knowing your
mom/dad/grandma, it is written somewhere under the mouse pad or in a file on
the computer call MyMasterPassword, waiting to be stolen.

------
dzhiurgis
Why don't browsers send password hashes instead of actual passwords?

This way password manager wouldn't have to store them in cleartext either.
Would be pain to enter them manually tho...

~~~
fpoling
Then stilling the hash is enough to login.

~~~
0xb100db1ade
So? If someone can steal the hash, they could probably hijack the session
anyway.

------
syllable_studio
I experimented with a similar idea, but with a solution that I think is
simpler. My idea is called "Skipper": A dead-simple password keeper that is
end-to-end encrypted, open-source, and free. A master password syncs your
encrypted database store from any decentralized cloud hosting service. It's
not fully featured yet, but others could add layers on top to add 2fa, proper
federation/decentralization, etc.

The prototype works, but is super rough. [https://github.com/syllable-
hq/skipper](https://github.com/syllable-hq/skipper)

~~~
minitech

      function loginAction(evt) {
        evt.preventDefault();
        const password = inputPasswordEl.current.value;
        props.db.getAllUsers()
          .then(querySnapshot => {
            const users = [];
            querySnapshot.forEach(function (doc) {
              const userObject = Object.assign({}, doc.data(), { id: doc.id });
              users.push(userObject);
            });
            const userFound = findUserMatch(password, users);
    

+

    
    
      export function findUserMatch(password, users) {
        return users.find(user => {
          return bcrypt.compareSync(password, user.userKey)
        });
      }
    

With modern React, I can’t tell whether this is server-side, client-side, or
potentially both. If it’s server-side, that’s ideal, because the way the
server stops responding to all requests for several minutes will make you fix
this before that Firebase query really starts costing (but still, why does
this exist). If it’s client-side, are you really exposing every user’s hash to
offline attack?

    
    
      export function saveMasterPassword(masterPassword) {
        const simpleCrypto = new SimpleCrypto(MASTER_PASS_SECRET);
        const cookies = new Cookies();
        const masterPass = simpleCrypto.encrypt(masterPassword);
        cookies.set(COOKIE_MASTER_PASSWORD, masterPass, { path: '/' });
      }
    

(uppercase values are server-side constants)

If you’re serving the same cookie encryption secret to everyone, is it really
a secret?

    
    
      function cypherObject(object) {
        const cookies = new Cookies();
        const masterPass = getMasterPassword();
        var simpleCrypto = new SimpleCrypto(masterPass);
        if (typeof object === 'object') {
          const object = JSON.stringify(object);
        }
        return simpleCrypto.encrypt(object);
      }
    

simple-crypto-js uses 100 rounds of PBKDF2 to derive an AES key from
`masterPass` here, so your brute-force resistance to an attacker with access
to the encrypted secrets comes from 100-round PBKDF2, not 2^10-round bcrypt.

I would recommend Bitwarden instead.

------
pkghost
You can do this with your brain and a text file (for keeping track of counters
and usernames). I've been managing my passwords this way for years.

~~~
viraptor
You mean you've been making new, unpredictable passwords by tracking only the
usernames and counters? You must be good at hashing ;) Seriously though: this
is going to be relatively secure only if each counter increase gives you
entirely random password.

------
HighPlainsDrftr
Why haven't we started using public/private key authentication yet? Most
systems have trust stores.

------
viraptor
The name is a bit unfortunate / harmful. LastPass exists. They can be more
creative.

~~~
kohtatsu
I really don't think it's a problem.

~~~
saagarjha
I for one misread it as "LastPass" the first time I saw the title.

~~~
baobabKoodaa
While we're at it, we might as well let LastPass have all the words that end
in "Pass".

------
dsego
Similarly there is getvau.lt which also has a command line version.

------
dagenix
no, no, no.

The way a stateless password manager like this works is that it defines some
function F(url, username, counter, settings, master_password) and F() returns
some random string which is the password for the site. The settings include
the characters to use (a-z, A-Z, 0-9, and symbols - each a boolean - so, 4
options for a total of 16 combinations; there is also a length parameter
defaulting to 16 - but lets assume that users primarily use 8 - 20 for a total
of 12 different values. This gives us a total of 12 * 16 = 192 total values
for the settings field). The user is expected to remember the counter in some
way - but the default is 1 and we can assume that most users have a counter
value somewhere between 1 and 10. The function F() hashes all this stuff up in
some sort of unchangeable way (changing it would modify every password and
would thus render the whole thing useless) and produces the random password.
Let's note: the url of the site and the username are both public information.
As above, the settings field has ~192 possible values. And the counter has ~10
possible values. The only thing that has significant entropy is the
master_password.

So, we have an equation that looks like: site_password = F(url, username,
counter, settings, master_password). But, as above, we know url and username
and there are only about 1,920 combinations that are likely for settings and
counter.

Let's say you use this to generate a password for some site that stores the
password in plain text. If an attacker gets that password, they now have the
opportunity to brute for the master_password value. A GPU based attacked can
attempt a very large number of passwords per second (hundreds of thousands to
billions per second, depending on how F() works) in a fully offline manner -
the only thing slowing them down is that each master password that they check
has to be rechecked against each of the 1,920 combinations for settings and
counter. This slowdown is extremely minor when the attacker can run a
tremendous number of guesses for the master_password in parallel. The settings
and counter field basically work as a salt - but unlike a real salt value that
would generally be a 32 or 64 bit number, this salt is super tiny.

Anyway, a competent attacker will figure out how to brute force the
master_password without too much effort. And the big problem is that that
master_password can then be used directly to calculate the site_password for
every other site that you log into. A couple reasonable guesses about what
counter you used and what settings you likely used for your bank (likely the
defaults) and the attacker is in.

The combination of settings and counter provide no real security. If a
password is stolen from some random low-value website, the attacker has an
easy way to figure out your master_password and thus your site_password for
actually valuable sites. You have no way to defeat this outside of changing
your master_password - which changes the site_password for every site you use
which more or less defeats the entire purpose of this scheme.

Realistically, the biggest security benefit of this scheme is that almost no
one uses this type of stateless password manager because of the other obvious
ergonomic problems (ie: you have to somehow remember the value of counter and
settings that you picked - which is a pain to do for more than a couple
websites). But, that is security through obscurity which has long been
(rightly) viewed as bad security.

Don't use this. Don't use any stateless password manager. It's fake security.

~~~
dagenix
Looking at [https://blog.lesspass.com/lesspass-how-it-works-
dde742dd18a4...](https://blog.lesspass.com/lesspass-how-it-works-
dde742dd18a4#.vbgschksh) \- its implemented using PBKDF2 w/ 100,000 iterations
with SHA-256. 100,000 iterations is nice as that is on the higher side for
what I understand the normal number of iterations of PBKDF2 to be. However,
PBKDF2 with SHA-256 is an ideal algorithm to brute force on a GPU. More modern
password hashing schemes such as bcrypt, scrypt, or Argon2 impose a much more
significant memory penalty which makes them much harder to brute force. But
since its impossible to change how F() works without changing every users's
password, this scheme will forever be stuck using PBKDF2 with SHA-256 and each
year as new, more powerful hardware comes out, this scheme will continue to
get weaker.

~~~
tottenhm
A thought experiment... which probably doesn't change the big picture... but
it's interesting...

Suppose the initial implementation chose an ill-suited/fast/cheap hash (like
MD5). The developer facepalms appropriately, changes course, and updates the
implementation to support an expanded list of 4 hashes (1 old/weak/cheap hash
and 3 new/strong/expensive hashes) - and you track the hash in the same way as
the counter.

Fast-forward a bit. Mallory eavesdrops, learns an example password, and starts
a brute-force attack for the master password. He doesn't know which hash to
use, so he has to try all of them. On the surface, the choice of hash is just
1 or 2 bits of entropy... but the resource impact on Mallory is driven by the
(in)efficiency of the new hash(es), so it has an outsized impact.

In anticipation of upcoming hardware, the developer issues annual updates with
another (slower) hashing option (PBKDF2 w/100k iterations => 150k iterations
=> 200k iterations). This muddies the waters for new brute-force attacks. It's
kind of a neat notion that the mere existence of a newer convention could
retroactively raise the cost of a brute-force.

Alas, it's not real. Because we're not just concerned that Mallory is an
_eavesdroper_ listening to a random password - we're concerned that Mallory is
a website-operator who takes user-registrations. In that case, he can simply
log the _time_ when the user or password was _created_ \-- and thereby rule-
out future hashing conventinos.

~~~
SloopJon
In general, these types of utilities don't treat the state (counters, password
rules, etc.) as a secret, so I wouldn't count on the hash type being secret
either. The security of this type of scheme depends almost entirely on not
being able to reverse a presumably known key derivation function such as
scrypt.

------
yetanotherjosh
Please try 1Password or LastPass before you shoot yourself in the foot with
something so unjustifiably insecure and functionally-hobbled as this. You'll
see those apps are no hassle at all, this stateless approach really doesn't
gain you anything but does cost you a lot.

What are the upsides to a stateless approach? Convenience/simplicity? When you
look at the guessing game you have to play to get the right login with this,
or the eventual personal state management you'll need to track exceptions,
it's certainly not simpler in practice. Price? LastPass is free for personal
use. Works offline? So do LastPass/1Password so long as you set them up first.
AFAIK there are literally no upsides to this.

What are the downsides? Review this thread, all the big ones have been
mentioned and there are more:

\- Master password cannot be changed

\- If master password is compromised, all your passwords are compromised,
regardless of device. (For proper password managers, master password gets
access only on the physical devices on which it's been synchronized and you
can revoke a stolen vault's online authorization remotely.)

\- Rotating a compromised password requires remembering you did it, or a
guessing game to find the right iteration of a counter variable.

\- Master password must be typed in full every time to get a site password.
This will encourage you to have a short master password.

\- Doesn't autofill login forms for you, requires copy/tab/paste.

\- Master password is typed into a web browser for every single password.
Browsers are generally a less secure runtime context than a native
application.

\- Doesn't remember the email/username you used for services.

\- Exceptions to password rules imposed by websites (length/character
requirements or exclusions) cannot be tracked

\- It's not always clear what the name of the site/service is to use for the
hash function inputs. Is is mybank.com or secure.login.mybank.com? Another
guessing game.

\- Many items above mean you will end up wanting some kind of state to track
the stuff this doesn't deal with, and now you've implemented your own state
solution which is surely far worse than what LastPass or 1Password have built.

One "upside" people might claim is that LastPass/1Password state servers can
be hacked (LastPass was hacked once I think?). But this actually isn't nearly
as bad as it sounds. If attackers get a bunch of (encrypted) vaults, they
still have to brute force every vault individually. Furthermore, these
providers have everything to lose in terms of reputation if they are hacked,
so are financially incentivized to maintain the highest degree of system and
software security. Compare that to this solution, which in every way trades
aways security and has basically nil financial incentive for secure
implementation.

 _I keep editing my post to add more reasons not to use this thing. Don 't use
it._

------
rolltiide
> Stop wasting your time synchronizing your encrypted vault.

Is this... actually a problem for anyone anywhere? Is this satire? Like when
someone made a networked string concatenation service and made it available on
Docker?

~~~
welly
No, it's not a problem. I don't remember when I last "wasted time
synchronising my encrypted database" because Bitwarden does it behind the
scenes without my knowledge.

