Horcrux: A Password Manager for Paranoids(arxiv.org)
arxiv.org
Horcrux: A Password Manager for Paranoids
https://arxiv.org/abs/1706.05085
167 comments
Wow. This is yet another example of the fatal combination of Rolling Your Own Crypto + Using OpenSSL Directly And Blowing Your Own Foot Off Because It Lets You.
A single hard-coded salt for key derivation:
Can everyone who is developing crypto apps Just Use NaCl/Libsodium?
var cipher = crypto.createCipher('aes-256-ctr', key.toString('hex'))A single hard-coded salt for key derivation:
const key = crypto.pbkdf2Sync(auth, '0945jv209j252x5', 100000, 512, 'sha512');
Can everyone who is developing crypto apps Just Use NaCl/Libsodium?
As an infosec guy, I'm honestly getting really tired of this. Virtually every time someone submits some new security tool to Hacker News, the author has made trivial, catastrophic, and what should be completely avoidable security mistakes.
So for the hundredth time, if you're not a cryptographer or experienced security engineer, please stop releasing and promoting your crypto-related projects before they have been vetted by someone who is. If this is something you intend to release, ideally run the basic idea by someone qualified first. By not doing so, you are doing active harm. Someone's life and/or liberty may very well depend on the software you write, and when you fail them in this regard you are ethically and morally responsible when these things are taken from them.
So for the hundredth time, if you're not a cryptographer or experienced security engineer, please stop releasing and promoting your crypto-related projects before they have been vetted by someone who is. If this is something you intend to release, ideally run the basic idea by someone qualified first. By not doing so, you are doing active harm. Someone's life and/or liberty may very well depend on the software you write, and when you fail them in this regard you are ethically and morally responsible when these things are taken from them.
Is there a good way to find people who are qualified to do such a review? This paper was written by a Ph.D. student and professor of Computer Science at a respected university. The professor teaches a crypto course on Udacity (https://www.udacity.com/course/applied-cryptography--cs387). If they don't meet the criteria for being cryptographers, I wonder how many people in the world do?
Not many. There's a Venn diagram to draw about academic cryptographers and practicing cryptographic engineers and people qualified to do cryptographic reviews and the overlap is less than you might think.
I'm going to push back on this a bit.
Thomas responded alongside this comment to talk about how academic cryptographers are not necessarily qualified to implement original crypto, and I largely agree with that; however, I don't actually think that's the issue here. Rather I would pin this on a lack of peer review.
I could be wrong, but I don't believe the author of this paper has had it published or at least accepted in any journal or conference proceedings. Being an eprint format with endorsement rather than peer review, you can expect mistakes like this to happen often, even if the authors are ostensibly qualified. When you submit original research for publication you generally go back and forth a bit with adjustments as needed, and as long as there is nothing egregious you don't need to redo it all.
In this specific case, I believe the author fully understands the issue (or would, were it presented to them) and is fully capable of fixing it. A qualified peer review would (hopefully :) have caught this and other latent issues if an HN commenter did.
We see this in the broader mathematics and computer science communities, and we especially see it in sub-disciplines like machine learning as well. It's absolutely true that academic cryptographers should not be assumed capable of rolling their own crypto a priori, but in my (educated) opinion I would certainly place far more weight on crypto developed by an academic cryptographer than a software engineer without any particular training.
My platonic ideal for someone who is capable of developing original crypto is something like an academic with a PhD in math or computer science (focusing on crypto), who can develop software very well and who joins an applied lab for crypto engineering and development (like NCC's) or a top cryptanalysis firm like Riscure. Failing that, I'd probably place the most weight on someone who had a lot of training in crypto engineering or practical cryptanalysis over an academic with no implementation experience.
(I apologize if any of this is patronizing, I don't know what your background or familiarity with the academic process is w/r/t peer review, etc).
Thomas responded alongside this comment to talk about how academic cryptographers are not necessarily qualified to implement original crypto, and I largely agree with that; however, I don't actually think that's the issue here. Rather I would pin this on a lack of peer review.
I could be wrong, but I don't believe the author of this paper has had it published or at least accepted in any journal or conference proceedings. Being an eprint format with endorsement rather than peer review, you can expect mistakes like this to happen often, even if the authors are ostensibly qualified. When you submit original research for publication you generally go back and forth a bit with adjustments as needed, and as long as there is nothing egregious you don't need to redo it all.
In this specific case, I believe the author fully understands the issue (or would, were it presented to them) and is fully capable of fixing it. A qualified peer review would (hopefully :) have caught this and other latent issues if an HN commenter did.
We see this in the broader mathematics and computer science communities, and we especially see it in sub-disciplines like machine learning as well. It's absolutely true that academic cryptographers should not be assumed capable of rolling their own crypto a priori, but in my (educated) opinion I would certainly place far more weight on crypto developed by an academic cryptographer than a software engineer without any particular training.
My platonic ideal for someone who is capable of developing original crypto is something like an academic with a PhD in math or computer science (focusing on crypto), who can develop software very well and who joins an applied lab for crypto engineering and development (like NCC's) or a top cryptanalysis firm like Riscure. Failing that, I'd probably place the most weight on someone who had a lot of training in crypto engineering or practical cryptanalysis over an academic with no implementation experience.
(I apologize if any of this is patronizing, I don't know what your background or familiarity with the academic process is w/r/t peer review, etc).
> A qualified peer review would (hopefully :) have caught this and other latent issues if an HN commenter did.
Would the qualified peer-review necessarily be reading the NodeJS code, or just checking the theoretical soundness of the paper? I'm not so certain about the former...
Would the qualified peer-review necessarily be reading the NodeJS code, or just checking the theoretical soundness of the paper? I'm not so certain about the former...
What blows my mind is that most of these errors we see in these tools submitted to HN are errors that were all covered in my 'Introduction to Cryptography' course I took when getting my CS degree.
People seriously need to stop rolling their own crypto.
People seriously need to stop rolling their own crypto.
5c from me:
1) why CTR mode was chosen? I would probably go with something like GCM: privacy + integrity check.
2) IV ideally should be re-generated on every re-encryption. It doesn't have to be secret, but has to be random (securely random).
1) why CTR mode was chosen? I would probably go with something like GCM: privacy + integrity check.
2) IV ideally should be re-generated on every re-encryption. It doesn't have to be secret, but has to be random (securely random).
GCM has exactly the same problem with respect to nonces (GCM, like CTR, has a nonce, not an IV, but the terms are unfortunately used interchangeably).
The secrecy/predictability/uniqueness rules for IVs and nonces depend on the specific cipher mode you're using, so be careful about writing generic recommendations. Also, be very careful with the word "ideally", because if you get an IV or nonce wrong, chances are your problems are much worse than "not ideal".
The secrecy/predictability/uniqueness rules for IVs and nonces depend on the specific cipher mode you're using, so be careful about writing generic recommendations. Also, be very careful with the word "ideally", because if you get an IV or nonce wrong, chances are your problems are much worse than "not ideal".
The good news appears to be that this has prompted some upstream discussion.
https://github.com/nodejs/node/issues/13801
https://github.com/nodejs/node/issues/13801
I opened an issue on the topic. https://github.com/HainaLi/horcrux_password_manager/issues/1
Alas, this is the very reason I wrote this blog post on stronger encryption in node.js:
http://vancelucas.com/blog/stronger-encryption-and-decryptio...
http://vancelucas.com/blog/stronger-encryption-and-decryptio...
The trick of entering a dummy username and password, which is then modified in the post request sounds a whole lot better than playing clipboard roulette or messing with the DOM.
This sounds pretty cool! What I'm wondering, is how they are intercepting the POST request and at what level?
I have not read yet, but my guess is they are taking all HTTP requests from the page and looking for their dummy username/password and replacing that. Not every login form (though we would like it) is in a form tag w/ an explicit action. Some SPA's will do an AJAX post of JSON w/ the credentials embedded (which is bad practice, but happens).
Actually, the more I think about it, I don't think I want this extension to do that...how does it know how long between when the fake fields are entered and when I press submit? Now I am going to read the paper...
Edit: Yup, the extension intercepts all network traffic even before you click submit. If you, e.g., hash on the client side this password manager will break. If you never click submit, this extension will continue to read all HTTP bytes from the page going back to the server it seems, looking for some strings...not sure the perf implications of this.
Actually, the more I think about it, I don't think I want this extension to do that...how does it know how long between when the fake fields are entered and when I press submit? Now I am going to read the paper...
Edit: Yup, the extension intercepts all network traffic even before you click submit. If you, e.g., hash on the client side this password manager will break. If you never click submit, this extension will continue to read all HTTP bytes from the page going back to the server it seems, looking for some strings...not sure the perf implications of this.
Out of curiosity, why is an AJAX post of JSON with credentials embedded bad practice?
Not bad practice from a security perspective per se, just annoying to users that don't want JS, or like the non-password fields to support their browser's features like autocomplete, etc. Granted if it's a SPA, some of that usability shop has sailed. And while any AJAX post is secure normally, many JS implemented login solutions open themselves up to CSRF and other problems.
You can have the form submit to a real address when js is disabled, and disable the form's behavior when js is enabled.
FYI Service workers can intercept and modify requests.
Only for the same origin they were installed on. So a generic solution like this one wouldn't really work as a service worker.
Also it is quite common that extensions ask for to be able to read all traffic. What would be stopping other extensions from being jerks?
Repository of the project:
https://github.com/HainaLi/horcrux_password_manager
https://github.com/HainaLi/horcrux_password_manager
If you are paranoid, then there is only one option, you are the password manager. Certainly not a piece of software you didn't author yourself. Else you are not truly paranoid.
That's only true for very specific threat models. For most people, the limit in entropy for your passwords implied by keeping them all in your head makes them more vulnerable than writing them down in a place with imperfect security.
I recently wrote a thing for myself to let me remember one password and generate different passwords for each of my accounts.
https://github.com/kybernetikos/sinkless
I like it because there isn't any third party or service for me to trust, but I can still have unique complex passwords for each purpose. It feels pretty much the same as having them all in my head.
https://github.com/kybernetikos/sinkless
I like it because there isn't any third party or service for me to trust, but I can still have unique complex passwords for each purpose. It feels pretty much the same as having them all in my head.
[deleted]
Similar: https://webpass.rkeene.org/
Though it does syncing
Though it does syncing
That's pretty cool. How does the syncing work? You should add emojis! :-)
It just posts an encrypted json blob to a CGI script that waits for another connection with the same ID. The script then connects those two connections so that anything one sends the other receives using a FIFO, so no disk involved and they can stream as much as they want to each other.
How do you deal with devices that do not support extensions?
Poorly at present, but it runs as a website on anything with a recent browser: https://kybernetikos.github.io/sinkless/ and you can copy and paste, or there is a node script that will generate the same passwords.
I'd like to make the UI work better in general, but in particular on mobile devices. But then I have many projects I'd like to make time for, and this one is probably usable enough for me for now.
I'd like to make the UI work better in general, but in particular on mobile devices. But then I have many projects I'd like to make time for, and this one is probably usable enough for me for now.
Are you trying to tell me what my threat model should be? That makes me suspicious...
No, actually only stating truly paranoid people would not use a 3rd party password manager. Else you still have somewhat trust in third parties, making you not paranoid.
Your reply however... stamps paranoid label on it :)
Your reply however... stamps paranoid label on it :)
If you were that paranoid you wouldn't be using a web browser in the first place. After all, its some 3rd party software that has access to your passwords.
There seems to be a growing chatter on HN and elsewhere about how you can't trust free software because you didn't audit/write it yourself.
I'm not sure if people actually believe that or use it as a way to point out how they're smarter than other people.
Sure its possible that the free software contains something malicious, but such an attitude is not constructive. If you only used software you wrote yourself you might as well not use a computer. There are degrees of trust, balancing of risks, and free software has a much better reputation of not containing malicious code.
There seems to be a growing chatter on HN and elsewhere about how you can't trust free software because you didn't audit/write it yourself.
I'm not sure if people actually believe that or use it as a way to point out how they're smarter than other people.
Sure its possible that the free software contains something malicious, but such an attitude is not constructive. If you only used software you wrote yourself you might as well not use a computer. There are degrees of trust, balancing of risks, and free software has a much better reputation of not containing malicious code.
Don't forget about the OS, you probably didn't write that software either (you are doomed)... and even if you keep your password on paper or in your head, there could be a keylogger when the time comes to use that password.
I'm paranoid enough to only use my own password manager, but if you must use a password manager written by someone else then don't use one that runs in a web browser. Moreover, although this doesn't apply in this case, don't use a password manager that stores anything on a server not totally controlled by you.
a piece of paper in your wallet is probably safer in many cases... but not as convenient
Rationally I'd say if you are truly paranoid then you'd assume that any security software you did author isn't secure enough since you acknowledge that humans, including yourself, are fallible. Thus you would prefer to use independently audited, battle tested, solutions (albeit ones that don't sync to the cloud).
If you can audit the code yourself, you can treat it as code you authored. (assuming you are competent to perform the audit)
Valid point.
https://github.com/HainaLi/horcrux_password_manager
It is in JS at least. Underhanded C is likely an easier trick to manage.
https://github.com/HainaLi/horcrux_password_manager
It is in JS at least. Underhanded C is likely an easier trick to manage.
True, in theory, though in practice, i know plenty of capable people but almost none of them bothers to read the openssh source (or even a subset, like recent changes) before updating or recompiling.
Make sure you read the code of the compiler you're using as well, and bootstrap/compile it from that source instead of trusting an existing compiler binary.
Why stop with compilers? Inspect the circuit diagrams for all your hardware and then make sure the actual manufacturing followed the designs to a tee.
I mean I know it hyperbole but I am pretty sure there are hardware bugs that allow access, see that Intel or IBM remote management disclosure. It might not a real backdoor but it's as good as one. As people above are mentioning keep your paranoia inside your threat model
I wish I could find the story where someone actually had this issue.
Basically, the story was that a program for grad research was inserting all kinds of nasty, anti-semetic things into text and it turned out the previous grad student had poisoned the compiler which was modifying the strings and was able to re-poison it every time through something else.
I forgot the exact details but it is an amazing read.
Basically, the story was that a program for grad research was inserting all kinds of nasty, anti-semetic things into text and it turned out the previous grad student had poisoned the compiler which was modifying the strings and was able to re-poison it every time through something else.
I forgot the exact details but it is an amazing read.
If you're able to find that, I'd love to read it.
Was a great read -- thanks!
> True, in theory, though in practice, i know plenty of capable people but almost none of them bothers to read the openssh source (or even a subset, like recent changes) before updating or recompiling.
Then they aren't paranoid but normal folks, eh?
Then they aren't paranoid but normal folks, eh?
What do you mean by "treat it as code you authored"?
For purposes of security paranoia, if you can perform a security audit on open source code it is just as good as any other code you've written.
Idk about other people but I find anything I don't find security holes in myself "as good" as anything I've written. I've got the same set of assumptions/blinders/competence either way.
Idk about other people but I find anything I don't find security holes in myself "as good" as anything I've written. I've got the same set of assumptions/blinders/competence either way.
This does NOT protect you from script injections, keyloggers, etc. Their approach in fact DOES.
I authored my password manager. It doesn't store the passwords anywhere.
Speaking of, why is there still no standard protocol for changing passwords? That's 90% of the barrier to managing passwords.
There's several. LDAPv3 ja kpasswd are some examples.
Three is no complete general agreement on best practise, and probably never will be as the risk factors involved are not entirely objective.
Any attempts to create a standard will result in several competing standards ending in this ubiquitous problem: https://xkcd.com/927/
Any attempts to create a standard will result in several competing standards ending in this ubiquitous problem: https://xkcd.com/927/
I haven't looked at the security of it yet, but the name alone is a winner for something you want to keep secret.
Why on earth isn't the industry moving away from per-site passwords? They are terrible. The fact that you need your own app to "manage" them is just evidence of how terrible they are.
People should be able to use their phones, Yubikey, TouchID, etc. as their authentication, without needing a password (except a master password for the phone/Yubikey/TouchID).
And yet I see no movement towards this from the industry. Are we stuck in this terrible state forever?
If I could see into the future I would dearly hope that in 10 years we are not seeing HN front page articles about the newest innovations in password managers.
People should be able to use their phones, Yubikey, TouchID, etc. as their authentication, without needing a password (except a master password for the phone/Yubikey/TouchID).
And yet I see no movement towards this from the industry. Are we stuck in this terrible state forever?
If I could see into the future I would dearly hope that in 10 years we are not seeing HN front page articles about the newest innovations in password managers.
Username/password is the least common denominator that's supported by everything and everyone.
If I make an integration with Yubikey or iPhone, then that works only for that style of authentication.
On the other hand, if I make simple username/password authentication, then all password managers in all browsers and with all devices will work for securely storing the authentication tokens.
The whole point is that sites don't (and shouldn't) make a decision about how the user should store all their credentials, otherwise some users would be prevented from using the password management process of their choice. Instead, they just ask for a random password and the user (or his/her devices) can store it however they want.
If I make an integration with Yubikey or iPhone, then that works only for that style of authentication.
On the other hand, if I make simple username/password authentication, then all password managers in all browsers and with all devices will work for securely storing the authentication tokens.
The whole point is that sites don't (and shouldn't) make a decision about how the user should store all their credentials, otherwise some users would be prevented from using the password management process of their choice. Instead, they just ask for a random password and the user (or his/her devices) can store it however they want.
I'm not sure I actually agree with this. Do you know of any studies that go into this?
My concern is around having a single source of failure/attack. Which, to be fair, is probably not that different than most people's scenarios. That is, most people just let their browsers and phones remember passwords. So, in practice this already happens. I just don't feel like it is safe. I'm highly interested in being challenged on this.
My concern is around having a single source of failure/attack. Which, to be fair, is probably not that different than most people's scenarios. That is, most people just let their browsers and phones remember passwords. So, in practice this already happens. I just don't feel like it is safe. I'm highly interested in being challenged on this.
I think the only way you avoid a single source of failure is if your brain is actually capable of remembering a separate, high-entropy password for every website you visit.
If you use the same password (even a high-entropy one) on every website, any hack of a single site compromises you on every website.
If you use a password manager to store high-entropy passwords for every site you visit, then the password manager is a single point of failure.
Both of these attacks happen in the real world. But securing a single authentication system like a phone app/Yubikey/TouchID/etc. seems more tractable than securing every website that you visit.
Password managers are available today, but since the websites you are using don't actually know about them, the integration and ease of use are not as great as they could be.
My vision is that you can use a phone app/Yubikey/TouchID/etc. to create as many identities as you want, and then you can use these to robustly authenticate to any website. To the website you would just be a GUID: an opaque identifier that it doesn't know anything about unless you tell it more. And all the app/Yubikey/TouchID does is let the website know (securely) that you are the same GUID that logged in last time.
If you use the same password (even a high-entropy one) on every website, any hack of a single site compromises you on every website.
If you use a password manager to store high-entropy passwords for every site you visit, then the password manager is a single point of failure.
Both of these attacks happen in the real world. But securing a single authentication system like a phone app/Yubikey/TouchID/etc. seems more tractable than securing every website that you visit.
Password managers are available today, but since the websites you are using don't actually know about them, the integration and ease of use are not as great as they could be.
My vision is that you can use a phone app/Yubikey/TouchID/etc. to create as many identities as you want, and then you can use these to robustly authenticate to any website. To the website you would just be a GUID: an opaque identifier that it doesn't know anything about unless you tell it more. And all the app/Yubikey/TouchID does is let the website know (securely) that you are the same GUID that logged in last time.
I primarily rely on resets, oddly. Drives me crazy when folks think I will actively try to remember a password that I do not use daily for more than a few days. If you have my email, you have everything you need to let me initiate a reset.
Which, I fully cede is also a single point of failure. Basically, I think we have plenty of weak links in the chains. I'm not too keen on codifying any new ones. If you have something that increases the strength of everything, I'm game to try it. And I am highly interested in studies that look into different strategies.
Which, I fully cede is also a single point of failure. Basically, I think we have plenty of weak links in the chains. I'm not too keen on codifying any new ones. If you have something that increases the strength of everything, I'm game to try it. And I am highly interested in studies that look into different strategies.
The industry is working on killing the password. It started at Google with U2F, handed over to the FIDO Alliance (an industry group) and is now being worked on by the W3C. Have you seen the Web Authentication work? https://www.w3.org/TR/webauthn/
[deleted]
A hundred times yes. Passwords should only ever have been allowed locally. When untrusted web sites started to demand passwords for authentication they went down the wrong path already. The industry (including OS and hardware makers) really dropped the ball on this one in the early days with scant support for physical token authentication that people could have gotten used to. Even Yubikey piggybacks on a USB port, when all the energy spent on idiotic fingerprint readers could have been better spent on creating a standardized, dedicated hardware key port.
I think all password managers that store passwords are flawed. Storage is a burden. The store must be synced between devices, secured, backed-up, etc. and it can be stolen. I believe that passwords should be deterministically generated when needed, not retrieved from a store. I'm not sure why this approach is not seen more often.
Edit: It seems people don't understand what I mean... I just put some code here to better explain: https://github.com/w8rbt/dpg
Edit: It seems people don't understand what I mean... I just put some code here to better explain: https://github.com/w8rbt/dpg
Because then you're out of luck when you need to update your password, say, due to a data breach at your target site. Or when the deterministically generated password doesn't meet the specific password requirements of the website. Or if somebody can capture your input "seed", they can generate all your passwords without needing to capture your password database like they would in another password manager.
Loosing the master password (or key or whatever) that is used to generate the passwords for a deterministic password generator is fairly similar to loosing the password database.
One is really not that much more secure than the other particularly when dealing with online websites.
But yeah if the site gets hacked you have to pick and remember an iterated password (ie a next iteration) or regenerate a new master password.
Of course if you are really paranoid you can always generate a password with dice and write that password down somewhere in safe place (ie offline password generation).
One is really not that much more secure than the other particularly when dealing with online websites.
But yeah if the site gets hacked you have to pick and remember an iterated password (ie a next iteration) or regenerate a new master password.
Of course if you are really paranoid you can always generate a password with dice and write that password down somewhere in safe place (ie offline password generation).
A very easy scheme could be:
Every time you need to change your password, (because it leaked), you simply generate a new nonce. You only store the nonce and the URL and this seems like a very secure scheme to me.
Cons: You can not change the master key after the fact, so make sure it's secure.
I'm not a cryptographer, so I'm probably missing something obvious
Edit:
We still need to solve the "password constraints" problem. I would say, we could add functions that given the password stored, deterministically creates a string from the password that adheres to some specific password scheme. For example, by using the password as a seed to a random number generator used to fuel traditional password generators like the one included in lastpass. The 'scheme' would also be stored next to the nonce and the url.
password = hmac(url++nonce, master_key)
Every time you need to change your password, (because it leaked), you simply generate a new nonce. You only store the nonce and the URL and this seems like a very secure scheme to me.
Cons: You can not change the master key after the fact, so make sure it's secure.
I'm not a cryptographer, so I'm probably missing something obvious
Edit:
We still need to solve the "password constraints" problem. I would say, we could add functions that given the password stored, deterministically creates a string from the password that adheres to some specific password scheme. For example, by using the password as a seed to a random number generator used to fuel traditional password generators like the one included in lastpass. The 'scheme' would also be stored next to the nonce and the url.
I tried doing that a few years ago, random password constraints made it highly impractical.
And if you end up using a database for storing your nonces and hashing schemes you'll end up with the same limitations and attack vectors the parent was complaining about.
And if you end up using a database for storing your nonces and hashing schemes you'll end up with the same limitations and attack vectors the parent was complaining about.
Hmm, sounds like you need a deterministic password weakener!
nonces and hashing schemes are not very sensitive information though. The nonce does not make the HMAC more predictible in any way
A well encrypted password store isn't more sensitive though. That's the whole concept behind services like lastpass that host an encrypted blob in the "cloud".
You could argue that it makes offline attacks easier because many encrypted storage formats have a way to check if the decryption was successful or not but you could remove this feature if that was a problem for you. And at any rate using a strong enough passphrase would make this attack impractical in the first place. And being notified when you used a wrong passphrase is pretty useful IMO.
You could argue that it makes offline attacks easier because many encrypted storage formats have a way to check if the decryption was successful or not but you could remove this feature if that was a problem for you. And at any rate using a strong enough passphrase would make this attack impractical in the first place. And being notified when you used a wrong passphrase is pretty useful IMO.
Isn't this basically what LessPass (https://lesspass.com/) does?
How could you generate passwords that satisfy arbitrary password constraints? Say example.com has a 20 character limit, must contain a capital letter and symbol (but not certain symbols), and can't contain a dictionary word. It seems to me like your generator would have to have an option for each constraint to satisfy, and you'd have to remember them at the time of retrieval (unless you store the settings).
Is there a different solution?
Is there a different solution?
I solved it in WebPass[0] by encoding the constraints for special (i.e., not generic) sites into rules associated with a unique ID, then only valid password are considered.
https://webpass.rkeene.org/
https://webpass.rkeene.org/
I don't think that's such a big problem for most users. The vast majority of websites impose only a few easily satisfiable constraints, at most: small and capital letters, numbers, symbols. This covers 99% of websites, and the default generator can cover this by default by generating something like bhAwG9$nj#.
For those corner cases you can have different password generators, for more complex constraints. But overall it's not a big hurdle.
For those corner cases you can have different password generators, for more complex constraints. But overall it's not a big hurdle.
I store the settings. It's either in the shell history or I just remember it. There are few services, notably online banking websites, that impose such requirements: ironically they are reducing the strength of my password scheme.
I use this tool to generate the passwords: http://hackage.haskell.org/package/scat
I use this tool to generate the passwords: http://hackage.haskell.org/package/scat
All such deterministic algorithms are seeded by something. This is their basic flaw. Guess the seed and you get all the passwords.
With a password manager that randomly generates unique passwords, you don't have that problem, but you do have to synchronize the data.
With a password manager that randomly generates unique passwords, you don't have that problem, but you do have to synchronize the data.
The master password of the password manager has the same issue plus the burden of storage.
It's not the same issue. With your approach, a compromise of the seed is catastrophic and reveals everything. With a regular password manager, you also need access to the vault encrypted using that master password. That's not a given -- most password managers either store their vaults locally or offer 2FA when synced.
(Nevermind that you can't change individual passwords or the master password at will with a deterministic scheme.)
(Nevermind that you can't change individual passwords or the master password at will with a deterministic scheme.)
and the virtue of allowing a single point of 2FA.
the seed is just the seed, and will always be the seed. the master password can change and be supplemented by 2FA / other enhancement schemes.
the seed is just the seed, and will always be the seed. the master password can change and be supplemented by 2FA / other enhancement schemes.
I'm not sure we're talking about the same thing. See the code I posted. There is no unchangeable static seed.
It is because of differences in password requirements. It is likely impossible to design a strong deterministic algorithm that doesn't require any per-site tweaks. Once you have per-site tweaks, remembering the exact tweak for each site has similar drawbacks as remembering per-site passwords. You can instead write the tweaks down somewhere, but that has similar drawbacks to writing down the passwords themselves.
I do this as well and wrote my own script also: https://github.com/agentgt/ezpwdgen
I mean sure its not the most secure thing and yeah you have to remember which iteration you are on once the site has some sort of databreach or makes you change your password but it generally works pretty well.
I mean sure its not the most secure thing and yeah you have to remember which iteration you are on once the site has some sort of databreach or makes you change your password but it generally works pretty well.
Deterministic (stateless) password managers have lots of usability issues which make them a pain to use in practice. Here's a good summary that I wrote up a while back: https://security.stackexchange.com/a/94128/29865
I have heard this idea put forth before, and I believe it is still flawed. See my response here:
http://nothingofvalue.org/password_manager.html#no_storage
Because passwords need to be changed (e.g., after a breach). Deterministically generating them does not allow this, unless you add additional information (such as appending an index, e.g. news.ycombinator.com|2), but then you need to store that somewhere...
I looked at your code. All it does is generate a password based on user-supplied input. This does not lessen the need for password managers. People still have to remember the input.
The fact that different websites have different password requirements/limitations is a big part of it
For those interested in related work, Mark Currie designed and patented one around 2008 that intercepts logins, injects correct credentials, and handles the TLS on a USB device. He described it to us on Schneier's blog as follows:
"The device is a small USB gadget that effectively acts as a SSL proxy, allowing it to have direct and first access to the clear text data to and from the host. It has a small user interface so it can accept (and optionally store) specific user input (PINs, passwords, credit card no, etc) and display specific user/server output data fields. This allows it to insert either pre-stored or on-demand passwords etc. into the outgoing stream. It also allows specific confirmation data fields from the server to be displayed e.g. a beneficiary account no., balance amount, etc.
So the actual passwords are only available in the comms path and PC-side in SSL-encrypted form and any confirmation fields (beneficiary account no., balance amount) are confirmed to the user via the integrated display just before being SSL-encrypted, so they cannot be manipulated before going to the server.
In terms of inserting a password, it automatically detects the standard HTML password form field and the corresponding response message (used by all secure web servers), and substitutes a dummy password for a real one. I have confirmed that this function works on all the major web sites e.g. PayPal, Amazon, E-Bay, Google, LinkedIn, etc. and at least four banks that I have checked (probably most).
For displaying server confirmations, it might require a little help from the host server in terms of detecting the HTML display field, or else it would need to store a profile for each website (not ideal). However, it costs the host service very little to tweak a bit of HTML.
I agree with you whole-heartedly about the user being in the loop. That is what my aim was with this device – The gadget directly authenticates the server through normal SSL and displays the server validity directly to the user via the integrated display. In Internet banking the main threat is the beneficiary account number. As long as the user is satisfied that the account number displayed on the device is correct then it cannot be manipulated other than by breaking the SSL crypto. In this it is almost identical to the IBM ZTIC. The difference is that it also allows the user’s password to be sent securely to the bank and therefore does not require the use of a client cert (so no private key needed)."
"The device is a small USB gadget that effectively acts as a SSL proxy, allowing it to have direct and first access to the clear text data to and from the host. It has a small user interface so it can accept (and optionally store) specific user input (PINs, passwords, credit card no, etc) and display specific user/server output data fields. This allows it to insert either pre-stored or on-demand passwords etc. into the outgoing stream. It also allows specific confirmation data fields from the server to be displayed e.g. a beneficiary account no., balance amount, etc.
So the actual passwords are only available in the comms path and PC-side in SSL-encrypted form and any confirmation fields (beneficiary account no., balance amount) are confirmed to the user via the integrated display just before being SSL-encrypted, so they cannot be manipulated before going to the server.
In terms of inserting a password, it automatically detects the standard HTML password form field and the corresponding response message (used by all secure web servers), and substitutes a dummy password for a real one. I have confirmed that this function works on all the major web sites e.g. PayPal, Amazon, E-Bay, Google, LinkedIn, etc. and at least four banks that I have checked (probably most).
For displaying server confirmations, it might require a little help from the host server in terms of detecting the HTML display field, or else it would need to store a profile for each website (not ideal). However, it costs the host service very little to tweak a bit of HTML.
I agree with you whole-heartedly about the user being in the loop. That is what my aim was with this device – The gadget directly authenticates the server through normal SSL and displays the server validity directly to the user via the integrated display. In Internet banking the main threat is the beneficiary account number. As long as the user is satisfied that the account number displayed on the device is correct then it cannot be manipulated other than by breaking the SSL crypto. In this it is almost identical to the IBM ZTIC. The difference is that it also allows the user’s password to be sent securely to the bank and therefore does not require the use of a client cert (so no private key needed)."
Perhaps this helps with trusting the password manager but it looks a bit complex to me.
Personally I'm more concerned about when I enter a master password that if there's a Trojan on my computer it's game over.
As most password managers are an encrypted database of sorts once it's encrypted all your passwords are out.
The only protection against that is some sort of 2FA.
Personally I'm more concerned about when I enter a master password that if there's a Trojan on my computer it's game over.
As most password managers are an encrypted database of sorts once it's encrypted all your passwords are out.
The only protection against that is some sort of 2FA.
You can also use a hardware token to handle the encryption/decryption (yubikey/nitrokey/GnuPG smartcard/...).
If you have a trojan on your computer it'll still be able to decrypt your passwords while the token is plugged and unlocked of course, but at least offline attacks shouldn't be possible. Of course that doesn't mean you shouldn't use 2FA wherever possible to mitigate the risks further.
Some tokens can also be configured to wait for a physical button press to allow the decryption which which can help prevent a complete background decryption of your passwords (assuming that each password is stored with a different key, like with password-store for instance).
If you have a trojan on your computer it'll still be able to decrypt your passwords while the token is plugged and unlocked of course, but at least offline attacks shouldn't be possible. Of course that doesn't mean you shouldn't use 2FA wherever possible to mitigate the risks further.
Some tokens can also be configured to wait for a physical button press to allow the decryption which which can help prevent a complete background decryption of your passwords (assuming that each password is stored with a different key, like with password-store for instance).
I guess if your system is compromised then password security becomes gravely threatened, no matter how secure the password manager may be. The only partial solution I can think of is to have the OS sandbox every application from every other.
Yep, pretty much. It really reminds me of this: https://xkcd.com/1200/ for obvious reasons.
The only ways I can think that would be able to prevent this are:
In all honesty, I could see buying an Android at a Pay as You Go place, and repurpose it to be a offline password manager. Never connect it to wifi, BT, cell. And any APK's you need you load via microSD card and USB.
The only ways I can think that would be able to prevent this are:
1. Physical non-networked device password manager
2. Really creative usage of SELinux
3. QubesOS
In all honesty, I could see buying an Android at a Pay as You Go place, and repurpose it to be a offline password manager. Never connect it to wifi, BT, cell. And any APK's you need you load via microSD card and USB.
Yes, the way to deal with trusting password managers is to use TFA as much as you can.
Too many problems with passwords, oauth and other things. There should be a standard auth protocol that is secure and works with everything out there. Why isn't there a successfully adoptef one yet?
This is my attempt in progress:
https://github.com/Qbix/auth
This is my attempt in progress:
https://github.com/Qbix/auth
Does anyone else think it's cool that Harry Potter fans are now old enough to be getting crypto papers published?
a password manager that is designed holistically
Honest question: what does 'holistically' mean in this context?
Honest question: what does 'holistically' mean in this context?
(co-author here)
Good question - it means the whole system (that is, both the client and server) were designed with the goal of limiting the exposure of the user's passwords in all ways we can - including time (not exposing them in the DOM and having the minimum possible exposure to the browser with acceptable user experience), code (minimizing the amount of code that has access to the user's credentials), and organizations (minimizing the trust the user has to put in any one provider).
Good question - it means the whole system (that is, both the client and server) were designed with the goal of limiting the exposure of the user's passwords in all ways we can - including time (not exposing them in the DOM and having the minimum possible exposure to the browser with acceptable user experience), code (minimizing the amount of code that has access to the user's credentials), and organizations (minimizing the trust the user has to put in any one provider).
It's fun that the authors readily admit that the idea is for paranoid people.
https://xkcd.com/538/
https://xkcd.com/538/
Being vulnerable to blunt objects does not mean you shouldn’t care about other attack vectors.
Overly focusing on one attack vector still leaves you vulnerable to many others. System designers need to consider risk:reward and effort:reward for users.
The paper offers an interesting but extreme extension into one aspect of security that users control. That is great to offer an extreme solution for the paranoid. If implemented well, even the less paranoid could use it.
Sadly this solution still offers less security than systems integrated into SSO/OAuth and 2FA.
The paper offers an interesting but extreme extension into one aspect of security that users control. That is great to offer an extreme solution for the paranoid. If implemented well, even the less paranoid could use it.
Sadly this solution still offers less security than systems integrated into SSO/OAuth and 2FA.
> Sadly this solution still offers less security than systems integrated into SSO/OAuth and 2FA.
OAuth implementations very often have vulnerabilities. Just look at how many Facebook had!
Not to mention 1) it doesn’t scale like passwords and 2) all the privacy implications.
As for 2FA it’s in addition to primary authentication scheme, like a password, not instead.
OAuth implementations very often have vulnerabilities. Just look at how many Facebook had!
Not to mention 1) it doesn’t scale like passwords and 2) all the privacy implications.
As for 2FA it’s in addition to primary authentication scheme, like a password, not instead.
Sticking with zx2c4 pass. It is an assembly of gnupg, git, and pwgen. Trusted open source components. Works with a Yubikey (opensc and gpg-agent) to prevent private key theft via software. PassFF extension provides excellent browser integration. Android Password Store and OpenKeychain allow pass and yubikey to work on my mobile. Strong 2 factor password storage everywhere I need it.
My biggest problem these days is dealing with sites that don't allow 30+ char passwords with full range of special characters. Almost exclusively, banks.
My biggest problem these days is dealing with sites that don't allow 30+ char passwords with full range of special characters. Almost exclusively, banks.
What is it with banks and their annoyingly terrible "security" requirements? My old bank once sent me an email saying I had to reset my password. The email seemed legit, but upon following the link therein something didn't seem quite right. So I use another device to visit my bank's site directly. Upon trying to login, I get redirected to the same form I reached from the email link and had a sinking realization that my bank did indeed expect me to fill in my name, address, SSN, DOB, debit card number, and PIN just to reset my password.
I sent a strongly worded email to a handful of people at the bank asking them if they really thought it was a good idea to teach their customers that its okay to click a link in an email claiming to be from their bank and provide that much personal information. I never got more than a canned response back, but several months later they did overhaul their password reset procedure to a more typical one.
I sent a strongly worded email to a handful of people at the bank asking them if they really thought it was a good idea to teach their customers that its okay to click a link in an email claiming to be from their bank and provide that much personal information. I never got more than a canned response back, but several months later they did overhaul their password reset procedure to a more typical one.
One time I found I couldn't log in to my bank account online. Called them up.
"Oh, we changed your username as a security measure."
Oh.
Wait, username??
"Oh, we changed your username as a security measure."
Oh.
Wait, username??
Typically management at financial institutions see "security reasons" as a quick way to end questioning from a customer.
Legacy software or partner integration requirements are almost always the reason for arbitrary changes within financial institution.
Anecdotally, I've never seen a scenario myself where this wasn't referred to as a "security measure" or similar. This includes within the institution to all non-technical employees.
Legacy software or partner integration requirements are almost always the reason for arbitrary changes within financial institution.
Anecdotally, I've never seen a scenario myself where this wasn't referred to as a "security measure" or similar. This includes within the institution to all non-technical employees.
They had good reasons to enact security measures as I was trying to get into my account internationally and I kept forgetting the password. I understand what you're saying though.
Makes me wonder if they didn't have any other way to disable logging in to the account. Which is worrying in a whole other way.
I suspect it's the same reasons nuclear launch facilities use floppy disks -- the solution is approved, and getting a new solution approved is viewed as too expensive/infeasible.
Not saying the argument is valid, just that it may be the reason.
Not saying the argument is valid, just that it may be the reason.
That and its proven to work, has a ridiculously long track use history (for software) so the bugs are fixed or well documented, and pretty damn hard to exploit. It's not like anyone is going to plug an 8 inch floppy disk they found laying in the rural Wyoming dirt parking lot into the nuclear silo master computer to check what's on it.
Yikes! Last time I looked, the intercontinental nuclear launch codes of any major power have not yet been proved to work.
But OK, I assume they still pass whatever dry-run test procedures exist. But if it is true that they are based on floppy-disks, then I don't think sticking with them is a net win for reliability and safety.
Bits rot, especially on floppies. So if they are still using them they have created procedures for refreshing the bits from backups. By now the floppies might be little more than ceremonial objects inside the systems that really determine the launch procedure.
And those systems would have evolved informally over time and might be ever-changing, poorly understood and poorly tested.
But OK, I assume they still pass whatever dry-run test procedures exist. But if it is true that they are based on floppy-disks, then I don't think sticking with them is a net win for reliability and safety.
Bits rot, especially on floppies. So if they are still using them they have created procedures for refreshing the bits from backups. By now the floppies might be little more than ceremonial objects inside the systems that really determine the launch procedure.
And those systems would have evolved informally over time and might be ever-changing, poorly understood and poorly tested.
On the other hand, when the collective idiocity better known as the Internet of Things finally comes back to bite us in the ass, we can at least be sure it wont be in the form of a nuclear winter.
I'm having a battle with HSBC in the UK at the moment and can't get past canned customer support responses either.
If there is a security issue with your card, HSBC Fraud department will send you a text, telling you to call them.
The text comes from an unknown number. The number you are told to call is not listed on their website anywhere.
At the same time they are sending letters to customers warning about how to protect from phishing attacks.
I've been trying to explain to them, that they are training their customers to accept phishing attacks, but they are having none of it.
Yes, I understand that they don't want to publicise their special number on the website - but at least put it on an unlinked page, so that if a customer visits hsbc.com and searches for the number it comes up in the results.
I really don't understand these people.
If there is a security issue with your card, HSBC Fraud department will send you a text, telling you to call them.
The text comes from an unknown number. The number you are told to call is not listed on their website anywhere.
At the same time they are sending letters to customers warning about how to protect from phishing attacks.
I've been trying to explain to them, that they are training their customers to accept phishing attacks, but they are having none of it.
Yes, I understand that they don't want to publicise their special number on the website - but at least put it on an unlinked page, so that if a customer visits hsbc.com and searches for the number it comes up in the results.
I really don't understand these people.
I've known banks that don't let you change the PIN on their cards - for "security" reasons. And banks with 5-digit maximum password lengths - "oh, it's strong enough, you need to use a token to get money out anyway" ... but not to login.
Many banks in Saudi Arabia have changed their standard for PIN length from 6 digits to 4 digits. I cannot comprehend why would anyone make such decision.
Many international withdrawals only do 4 digits which means 6 digits in your home country becomes meaningless...
The IT community should launch a campaign against the stupidity of banks' security procedures, which discredit our jobs...
I think it's OK to have short passwords if you block access after a few wrong login attempts. The password reset Form you've described is ridiculous, though.
Your anecdote describes a very bad behaviour, but the generally simple requirements banks have is a necessity of dealing with the general public. The more complex the requirements, the more customer support with tech naifs you need. And overall, it generally kind've works for them; there are some slips through the cracks, but fraud isn't rampant - banks accounts have been successfully run this way for years for the vast majority. Make it harder for people to get their money and you've created a significant friction point that will see your less tech-savvy clients almost literally flee to other banks.
The problem with this is that if that if there is a breach your typical bank will not take responsibility and claim that the customer is liable.
It needs to be written into law in all jurisdictions, that if a bank has been negligent in security, then when responsibility for a breach is unclear the benefit of the doubt should be given to the customer and the breach classified as a bank robbery.
It needs to be written into law in all jurisdictions, that if a bank has been negligent in security, then when responsibility for a breach is unclear the benefit of the doubt should be given to the customer and the breach classified as a bank robbery.
Talking about bank, when i tried changing my transaction password my bank sent me an acknowledgment letter which had to be submitted physically to the bank again with all the details filled onto the form then you have to wait in the queue to get signatures and approval. All being said the worst part was that the letter took more than 2 weeks to arrive at my home and the letter had transaction password which you have to change again.
My bank requires a number in the password and in the username, but doesn't seem to do any validation that the two inputs contain different numbers before storing them.
I imagine a lot of customers are using the same number in each.
I imagine a lot of customers are using the same number in each.
Pass looks great. There are still a few reasons though why I can't bring myself to switch to it from KeePass.
1. As far as I can tell, only the passwords are encrypted; not the entire database. This is a little annoying from a privacy standpoint; since it means I have to trust whatever cloud storage system I'm using with a list of every site I have an account on.
2. No decent browser autofill. Yes, there's browserpass, but as far as I can tell it requires manually searching your password database for the site you're on, which is somewhat inconvenient and doesn't help at all against phishing attacks.
3. No InputStick support. This means if I ever have to enter a password on a computer that doesn't have pass installed, I need to open my password DB on my phone and manually retype the necessary password instead of being able to just auto-type it.
4. No autotype on desktop - This isn't quite as big of a deal, since most programs will let you copy/paste passwords just fine, but as far as I can tell no pass desktop clients include support for auto-typing login credentials. For many non-web apps that require passwords that feature is extremely helpful.
If these ever get fixed, there's a decent chance I'd switch.
1. As far as I can tell, only the passwords are encrypted; not the entire database. This is a little annoying from a privacy standpoint; since it means I have to trust whatever cloud storage system I'm using with a list of every site I have an account on.
2. No decent browser autofill. Yes, there's browserpass, but as far as I can tell it requires manually searching your password database for the site you're on, which is somewhat inconvenient and doesn't help at all against phishing attacks.
3. No InputStick support. This means if I ever have to enter a password on a computer that doesn't have pass installed, I need to open my password DB on my phone and manually retype the necessary password instead of being able to just auto-type it.
4. No autotype on desktop - This isn't quite as big of a deal, since most programs will let you copy/paste passwords just fine, but as far as I can tell no pass desktop clients include support for auto-typing login credentials. For many non-web apps that require passwords that feature is extremely helpful.
If these ever get fixed, there's a decent chance I'd switch.
> 4. No autotype on desktop - This isn't quite as big of a deal, since most programs will let you copy/paste passwords just fine, but as far as I can tell no pass desktop clients include support for auto-typing login credentials. For many non-web apps that require passwords that feature is extremely helpful.
I may not understand what you mean by "autotype on desktop", but I use the dmenu password-store extension which is the executable "passmenu". It allows the command line option "--type" which is quite close I think to what you desire.
I may not understand what you mean by "autotype on desktop", but I use the dmenu password-store extension which is the executable "passmenu". It allows the command line option "--type" which is quite close I think to what you desire.
Yeah, that's basically what autotype is on KeePass; except KeePass is a bit more flexible since it lets you configure custom autotype sequences (e.g. `<username><tab><password><tab><enter>`) on a per-application basis.
This seems like a fairly decent substitute if you're on Linux. Doesn't look like it'll work on Windows or MacOS though.
This seems like a fairly decent substitute if you're on Linux. Doesn't look like it'll work on Windows or MacOS though.
rofi-pass (based on rofi, a dmenu alternative) allows for custom autotype sequences.
I use KeePassX, but I haven't figured out how to do any of these fancy things. What do you use for browser autofill, InputStick, autotype, etc?
Also how do you store your password file and sync across devices?
And what do you use on iOS? I haven't found a very convenient workflow for my phone. No phone app I've found can keep synced with a password file that's stored on Google Drive.
Also how do you store your password file and sync across devices?
And what do you use on iOS? I haven't found a very convenient workflow for my phone. No phone app I've found can keep synced with a password file that's stored on Google Drive.
I'm using KeePass Professional Edition, not KeePassX. Pretty sure they both use the same database format and are both cross-platform, so you should be able to switch pretty easily if KeePassX doesn't do everything you want.
For browser autofill I'm using the KeePassHttp plugin with ChromeIPass.
For InputStick I'm using Keepass2Android with KP2A InputStick.
Autotype is a built-in feature of KeePass on desktop.
Password database is stored on Google Drive, encrypted with a 2-part file and password based key. The file-based component of the key is stored locally offline on all my devices. Changes to the database get synced automatically by Google Drive on my PCs and by Keepass2Android on my phone.
I'm not sure about iOS, unfortunately. My phone is running Android, so I haven't really looked into KeePass clients for iOS.
For browser autofill I'm using the KeePassHttp plugin with ChromeIPass.
For InputStick I'm using Keepass2Android with KP2A InputStick.
Autotype is a built-in feature of KeePass on desktop.
Password database is stored on Google Drive, encrypted with a 2-part file and password based key. The file-based component of the key is stored locally offline on all my devices. Changes to the database get synced automatically by Google Drive on my PCs and by Keepass2Android on my phone.
I'm not sure about iOS, unfortunately. My phone is running Android, so I haven't really looked into KeePass clients for iOS.
What is KeePass Professional Edition? When I Googled for that the best thing I could find is "Professional Edition" on this page: http://keepass.info/download.html
Is that what you mean? It looks like it's written using Mono for non-Windows platforms. I might have shied away for that reason. What platform do you use it on? I'd love to know if it works well on non-Windows platforms (OS X, Linux).
Is that what you mean? It looks like it's written using Mono for non-Windows platforms. I might have shied away for that reason. What platform do you use it on? I'd love to know if it works well on non-Windows platforms (OS X, Linux).
Yes, that's what I'm referring to. I mostly use it on Windows, so I can't really comment on how well it works on MacOS or Linux. My understanding though is that it's basically a straight port, so most of the same functionality should be available.
Another option you might want to look at is KeePassXC. It's a fork of KeePassX, and it has built-in (though off-by-default) support for keepasshttp.
Another option you might want to look at is KeePassXC. It's a fork of KeePassX, and it has built-in (though off-by-default) support for keepasshttp.
"so I can't really comment on how well it works on MacOS or Linux."
Linux: rock solid for several years now. We have several KP databases shared by 20 odd people that contain several thousand entries. I use it on Gentoo and Arch desktops. It runs under Mono plus a few extras to do things like sending links to browsers and autotype etc.
Linux: rock solid for several years now. We have several KP databases shared by 20 odd people that contain several thousand entries. I use it on Gentoo and Arch desktops. It runs under Mono plus a few extras to do things like sending links to browsers and autotype etc.
Not OP but I do some of these things with KeePass as well.
For autofill, KeeFox works well for me on Firefox - there's probably something similar for Chrome. I think KeePass will do autotype if you right-click on an entry but it's not a feature that I really use so I'm not sure.
I store my password DB in my home folder and use syncthing to synchronize it to my other computers and my phone.
I don't know about iOS but I use KeePassDroid on Android and it works pretty well.
For autofill, KeeFox works well for me on Firefox - there's probably something similar for Chrome. I think KeePass will do autotype if you right-click on an entry but it's not a feature that I really use so I'm not sure.
I store my password DB in my home folder and use syncthing to synchronize it to my other computers and my phone.
I don't know about iOS but I use KeePassDroid on Android and it works pretty well.
1. Check out [pass-tomb](https://github.com/roddhjav/pass-tomb). Unfortunately this only resolves that issue on Linux. Their websites [here](https://www.dyne.org/software/tomb/).
The others are things I've noticed as well, and do wish to see implemented.
The others are things I've noticed as well, and do wish to see implemented.
1. In pass everything is encrypted but you have to give names to each gpg encrypted password file.
2. Right. I use rofi-pass on Linux which fills in the selected password or other login data without any clipboard action.
3. True. Never thought about this but sounds clever.
4. Same answer as in 2.
Plus I have a good password history through the git commits. Of course I push it just in my local network.
And I use more then just one password store. And inside you can folder based decide who can decrypt the passwords and who not.
2. Right. I use rofi-pass on Linux which fills in the selected password or other login data without any clipboard action.
3. True. Never thought about this but sounds clever.
4. Same answer as in 2.
Plus I have a good password history through the git commits. Of course I push it just in my local network.
And I use more then just one password store. And inside you can folder based decide who can decrypt the passwords and who not.
1. Right, that's what I meant; the file and directory names aren't encrypted, which probably reveals which sites you have an account on. Sorry for the confusion.
2. Is that really auto-fill though? Seems more like KeePass's auto-type. I meant like a browser extension that knows what site you're on and fills in the appropriate username/password combo automatically.
4. Cool, that looks like a decent solution for auto-typing. I hadn't heard of that before. Linux-only though from what I can tell, so it won't work for me in the general case.
KeePass has built-in password history too, but I do really like the idea of using git for that; that's one of the reasons why I'm interested in pass.
2. Is that really auto-fill though? Seems more like KeePass's auto-type. I meant like a browser extension that knows what site you're on and fills in the appropriate username/password combo automatically.
4. Cool, that looks like a decent solution for auto-typing. I hadn't heard of that before. Linux-only though from what I can tell, so it won't work for me in the general case.
KeePass has built-in password history too, but I do really like the idea of using git for that; that's one of the reasons why I'm interested in pass.
This article is about a novel technique that supplies dummy passwords on DOM level and intercepts network requests to replace them with actual secrets. This is not about protecting your master key, it’s about protecting the actual passwords from a variety of attacks, including script injection.
Your comment is completely off-topic.
Your comment is completely off-topic.
I used pass for a while before I moved on to gopass. It's a drop-in replacement for pass with a bunch of useful features (like encrypting a password-store for multiple people, or "mounting" password stores). Hope it gets picked up and supported more, it's pretty nice.
https://github.com/justwatchcom/gopass
https://github.com/justwatchcom/gopass
You might also want to consider hunter2, it's similar but with smartcards.
https://chiselapp.com/user/rkeene/repository/hunter2/
https://chiselapp.com/user/rkeene/repository/hunter2/
What a fantastic name.
While these systems shouldn't have these length limits, a 25-character pure alphanumeric random password already has nearly 149 bits of entropy, which might be stronger than other cryptographic primitives that are use in these systems, if you trust that there are no effective attacks against your RNG. Brute force against such a password may already not be the easiest way to attack the systems that use it.
Oh, this looks wonderful. I've used one big gpg encrypted file for years, still better than all password managers I tried.
I'm wondering if there is a way to combine find and show with pass though. Like pass find <keyword> and show the password in one command. I realize I could probably use the grep command, but then I'd have to put the keyword into the encrypted file as well, and I'd need to decrypt all files to find it.
Edit: Gah, I was just thinking this should just be an alias, but the output of pass find can't just be fed to show either..
I'm wondering if there is a way to combine find and show with pass though. Like pass find <keyword> and show the password in one command. I realize I could probably use the grep command, but then I'd have to put the keyword into the encrypted file as well, and I'd need to decrypt all files to find it.
Edit: Gah, I was just thinking this should just be an alias, but the output of pass find can't just be fed to show either..
Side note; I thought Yubikey was not open source. Am I mistaken?
https://www.yubico.com/2016/05/secure-hardware-vs-open-sourc...
https://www.yubico.com/2016/05/secure-hardware-vs-open-sourc...
NEO has open source OpenPGP applet (in contrast of 4) but if you read the link carefully they provide rather strong points why it doesn't matter and closed hardware can even be more secure.
Just thought I would mention: PassFF does not works with the current version of firefox. The current plugin does not work and is not supported. According to the author, we should wait for the Web-Extensions version which will be coming... no idea... soon? I asked about 2 months ago. So pass is basically just a command line password manager unless you run firefox developer edition.
You can use browserpass [1] instead, it's a web extension for Firefox and Chrome.
[1] https://github.com/dannyvankooten/browserpass
[1] https://github.com/dannyvankooten/browserpass
I just used PassFF this weekend on a fully patched Ubuntu LTS. It worked perfectly.
Sometimes I think there should be a list of sites that don't allow long passwords - so that people can be aware of sites that don't take passwords seriously.
no what you are looking for but there's http://plaintextoffenders.com/ ...
Link (slightly tricky to find): https://www.passwordstore.org/
I use hashicorps Vault for keeping all my secrets. And never looked back.
I don't think their scheme results in different keys for each site, but I could be wrong.
[0] https://github.com/HainaLi/horcrux_password_manager/blob/mas...
[1] https://nodejs.org/api/crypto.html#crypto_crypto_createciphe...