I am pretty sure the code is reusing IVs for AES-CTR[0] (i.e. the encryption is worthless), because it doesn't specify an IV and Node seems to derive the IV from the key.[1] This seems like a massive footgun in Node.
I don't think their scheme results in different keys for each site, but I could be wrong.
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.
var cipher = crypto.createCipher('aes-256-ctr', key.toString('hex'))
Besides the completely fatal error of using derived and non-unique IVs (fatal as in, if you encrypt more than 1 item with it, it is exactly as good as plaintext because any two items encrypted with the same key+iv in CTR mode cancels out to plaintext), isn't using hex encoding vastly constraining the possible complexity-per-byte of the key?
Again, the salt is only lowercase alphanumeric. This makes this 120-bit salt really just a 77-bit salt. But since it's hard-coded and not randomly generated, it's a 0-bit salt.
Can everyone who is developing crypto apps Just Use NaCl/Libsodium?
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.
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'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.
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).
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.
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.
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.
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/
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
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.
You then store url and nonce. it's no problem that this info is public as far as I know, but perhaps you could again encrypt both the URL and the Nonce using symmetric encryption using the 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.
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).
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 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
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.
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)."
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).
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.
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?
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).
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.
[+] [-] iancarroll|8 years ago|reply
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...
[+] [-] analogist|8 years ago|reply
A single hard-coded salt for key derivation:
Again, the salt is only lowercase alphanumeric. This makes this 120-bit salt really just a 77-bit salt. But since it's hard-coded and not randomly generated, it's a 0-bit salt.Can everyone who is developing crypto apps Just Use NaCl/Libsodium?
[+] [-] letharion|8 years ago|reply
[+] [-] vlucas|8 years ago|reply
http://vancelucas.com/blog/stronger-encryption-and-decryptio...
[+] [-] Nyubis|8 years ago|reply
[+] [-] baby|8 years ago|reply
[+] [-] pspeter3|8 years ago|reply
[+] [-] posnet|8 years ago|reply
https://github.com/HainaLi/horcrux_password_manager
[+] [-] thinkMOAR|8 years ago|reply
[+] [-] MatthewWilkes|8 years ago|reply
[+] [-] _jal|8 years ago|reply
[+] [-] JohnStrange|8 years ago|reply
[+] [-] laumars|8 years ago|reply
[+] [-] fictioncircle|8 years ago|reply
[+] [-] deno|8 years ago|reply
[+] [-] my_ghola|8 years ago|reply
[+] [-] pishpash|8 years ago|reply
[+] [-] ptman|8 years ago|reply
[+] [-] dspillett|8 years ago|reply
Any attempts to create a standard will result in several competing standards ending in this ubiquitous problem: https://xkcd.com/927/
[+] [-] crusso|8 years ago|reply
[+] [-] haberman|8 years ago|reply
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.
[+] [-] PeterisP|8 years ago|reply
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.
[+] [-] taeric|8 years ago|reply
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.
[+] [-] Rafert|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] pishpash|8 years ago|reply
[+] [-] w8rbt|8 years ago|reply
Edit: It seems people don't understand what I mean... I just put some code here to better explain: https://github.com/w8rbt/dpg
[+] [-] jacobwg|8 years ago|reply
[+] [-] arianvanp|8 years ago|reply
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.
[+] [-] brbz|8 years ago|reply
Is there a different solution?
[+] [-] patrickmn|8 years ago|reply
With a password manager that randomly generates unique passwords, you don't have that problem, but you do have to synchronize the data.
[+] [-] sanderjd|8 years ago|reply
[+] [-] agentgt|8 years ago|reply
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.
[+] [-] Ajedi32|8 years ago|reply
[+] [-] AdmiralAsshat|8 years ago|reply
[+] [-] fredley|8 years ago|reply
[+] [-] abalone|8 years ago|reply
[+] [-] captbaritone|8 years ago|reply
[+] [-] nickpsecurity|8 years ago|reply
"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)."
[+] [-] 1ba9115454|8 years ago|reply
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.
[+] [-] simias|8 years ago|reply
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).
[+] [-] Santosh83|8 years ago|reply
[+] [-] snowwrestler|8 years ago|reply
[+] [-] EGreg|8 years ago|reply
This is my attempt in progress:
https://github.com/Qbix/auth
[+] [-] cbhl|8 years ago|reply
[+] [-] stinos|8 years ago|reply
Honest question: what does 'holistically' mean in this context?
[+] [-] dave1629|8 years ago|reply
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).
[+] [-] tIONTamINariciA|8 years ago|reply
https://xkcd.com/538/
[+] [-] danjoc|8 years ago|reply
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.
[+] [-] X86BSD|8 years ago|reply