I stumbled across the Obliviate password manager just recently. It doesn’t store passwords, it generates them based upon info you feed it (website or some other identifying information you provide and a password you use that doesn’t change, much like a password manager). If you give it the same info twice, you get the same password twice, and in this way no password is stored anywhere.
Seems like a novel idea, at the very least. Has anyone tried this or would like to share some thoughts?
The basic principle is very simple.
You could, as well, create a textfile with the URL and the the cipher key (correct horse battery staple)
and hash it. Or on the command line, e.g.
echo puri.sm correct horse battery staple | sha256sum
and then use the output as a password.
If the (hashing) algorithm used is considered good, then it should be safe.
(Actually, I just checked: the project that inspired this one, basically just does what I wrote there)
Pro:
Contra:
The first two are mitigated by the fact that you could define a set of “important” passwords which you either don’t use the same technique or slightly alter (append) the cipher key
In this example, hash output is hexadecimal, right? That doesn’t leave much entropy. So there would have to be a good way to convert that output into letters after f and other symbols and stuff. Is that something that has to be done…properly? Securely? Whatever the appropriate adjective is?
That’s just the way it is output by that particular command, not the way it must be output e.g. by a different tool. It looks as if the actual tool is using base 85.
A hash could be construed as being an array of bytes. In order to output for a human, you can
I wouldn’t exactly agree with that.
In one sense, the hash has the same amount of entropy regardless of how it is output. There are fewer symbols in base 16 but the output will be longer.
In a different sense, the actual entropy is in the passphrase (correct horse battery staple) and it has the same entropy for all web sites and regardless of how it is output.
Looks as if it is actually using PBKDF2, which I think is considered good. PBKDF2 is used by WiFi to derive the underlying shared secret key from the SSID and PSK (passphrase).
Also painful if a company gets taken over and they eventually retire the old domain i.e. in that situation you either need to type in the old domain long after the retirement or you need to change the password when the domain changes.
Correction: It looks as if the actual tool is using the base 85 alphabet, but not doing proper base 85 encoding.
That would appear to have minor, not dramatic, security implications i.e. it would still be fit for purpose.
I don’t think you need to use the domain. You could use “where I stash my code” just as easily as “github” or “github.com”.
I have heard of that method before and I think in has weaknesses. Maybe these can be overcome but I don’t see this ATM, although I have to admit that I did not spend much time to think about it.
E.g. what if you need to change the password for a site? One could add a variable representing the password’s iteration but than you would have to start memorizing the iterations for your sites. Or you need a file that stores that information, so you are back at something similar like a ppassword database. Maybe it is a bit better because there’re no plain text passwords stored in that file, but in case it gets cracked those can be generated if the master password is revealed in this case.
What I would like to see is that most passwords could be handled under the hood without bothering the user with the details.
Imagine service providers and client vendors aggree on a password specification, e.g. 512bit long passwords. And services get an API to securely register/deregister, login/logout and change password. Than a client could generate long random numbers (the most secure passwords ever) under the hood and exchange it with the service. The user doesn’t have to see the passwords. They are no words or something meaningful. The user never has to type or memorize passwords. With traditional random passwords it could still happen that the password coincidentally consists of meaning words which can be attacked by a dictionary attack. I admit this is probably a really rare case, but when passwords are usually not created by humans it doesn’t make much sense anymore to run a dictionary attack at all.
You could change the name of the site, eg “github” becomes “new github” or “github24sep” or whatever. Perhaps that would have to be written down or logged somewhere, but it isn’t the sensitive part of the information.
Your password API idea reminds me of the notion of an online identity like Sia Skynet’s MySky. A logical evolution from former to latter, I would think, but that’s for another thread.
For a small number of things that need identifying information perhaps. I don’t know about you but I have literally hundreds of passwords (web sites, devices, email, …). If I invented some cutesy phrase to identify each ‘thing’ that needs identifying information then I would rapidly need some additional storage in order to keep track of all the phrases! That could be a piece of paper (not so good), a text file or perhaps a password manager. (You would not need to provide high security for that information to prevent someone else getting hold of it but it would be important not to lose it.)
In other words, when you come back to github.com after a period of absence, you have to remember whether the phrase was “Where I stash my code”, “where I stash my code”, “where I stashed my code”, “where I store my code”, …
So I think you would need rigorous conventions about how identification is done (e.g. web sites by domain name with or without username, devices by unqualified or fully qualified hostname - as appropriate - with or without username, email by email address). Whatever conventions work for you …
What if you need to change the master password? e.g. because it is compromised
If it makes you feel better, it’s case insensitive.
Yes, you are correct.
(If you only use the domain name as the “info” then that is fine. I can only think of obscure cases where it wouldn’t be fine more generally.)
Another observation about the general approach (and hence why crypto design should be left to the experts and even crypto review should be left to the experts) … this code is taking a crypto function (PBKDF2) that was designed for one purpose and using it for a different purpose. That can be risky because the function as originally designed may be secure in its original purpose but weaker or broken in the other purpose.
I don’t see any weakness but there are people a lot smarter and a lot better resourced on the internet trying to break these things if it is worth their while.
Perhaps it’s like using vice grips as a door handle? It’s still doing the same thing it was designed to do, just in a different capacity (and for my part, I don’t know if it is or not).
Let me elaborate just a little: Crypto functions are designed under assumptions about what inputs and outputs are secret and what inputs and outputs are public.
Comparing PBKDF2 as used for key stretching in WiFi with PBKDF2 as used in the above software, the details about what is public differ - and that makes me nervous. That doesn’t mean that it is broken but it does mean that I would be looking around for expert crypto review before considering using it.
Yeah, fair enough.
But I don’t hate this idea, even if its only use is as a novelty. It certainly solves the “who has my passwords and can I trust them” dilemma.
