[deleted]
How to Safely Store Your Users' Passwords in 2016
151–160 of 321 posts
Re: How to Safely Store Your Users' Passwords in 2016
#152Earlier quoted context omitted.
How are you going to calculate the scrypt hash, client-side? Doesn't that scrypt hash then become the password, from the server-side application's perspective? How are you storing the salt for the user if your server only knows about a SHA-256 hash. > MITM attacks won't get access to unencrypted fields. That's TLS's job. If you, for example, are building a web app and you're delivering Javascript to perform the scryp…
Very valid questions. Let me try to answer them and let's see if those answers are valid or not. Yes, the scrypt hash just becomes the password for the server. However, this password is going to be unique and almost impossible to guess. Salting this password on server side doesn't give us any additional benefits. The server can store the salt that the client used, though. Yes, the MITM point was minor. Just another m…
I think the simplest thing is for the server to generate a salt for every user and add a step for the client to request the salt for a given user. If you want to protect against account enumeration then you need to be able to generate consistent salts for accounts that don't exist also.
Re: How to Safely Store Your Users' Passwords in 2016
#153Earlier quoted context omitted.
The article offers specific advice for Java-without-libsodium, but it offers no such specific advice for Java-with-libsodium. There would appear to be three distinct Java bindings of libsodium.
(I'm not ignoring your comment, I'm currently debating whether to update it to include libsodium example code or to write a separate post for that.)
Write a separate post and then link to that from your current post. Best of both worlds :D
Re: How to Safely Store Your Users' Passwords in 2016
#154Serious question: What about using a Public/Private key encryption to store the password? - Private key is stored in a secure place. Offline for all i care; printed on a piece of paper; memorized and swallowed. - When user creates the account - password is padded with salt, then a public key is used to encrypt it. The resulting encrypted form is stored, along with the salt. - When user attempts to authenticate - the…
The more standard way to migrate passwords/authentication schemes is to do it on login. So if you want to switch to scrypt from some other format, wait for them to login, check their password via the old method, then rehash the password with the new method. Store in the database which method was used.
If you're switching to a non-password based system like OAuth, make users link their accounts after logging in with their password. If you are going to completely drop the password, then send each user an identifiable link where they can link their account.
Re: How to Safely Store Your Users' Passwords in 2016
#155Earlier quoted context omitted.
Wouldnt this happen with pretty much anything that is not threaded by default? Clearly with PHP you give a fuck, but i assume its not different with Ruby, Python, Go, ASP or anything else. You just usually use them threaded.
PHP is usually deployed in a FastCGI multiprocess setup, so the server will keep handling requests on the other processes while the hashing process is blocked. I wonder whether threading really saves you, given that there are only so many cores in a system and password hashing is CPU heavy. Naively it seems a DoS would involve sending as many parallel requests as there are cores, which is not a lot and can easily be…
I know thats what i ment with usually you give a fuck, i dont know any way you could run PHP single threaded on a server (i mean there sure is). But its something common you learn when you programm in the other languages i mentioned.
I dont think it could get a real issue in a real environment, except someone really wants to fuck with you. But the some fail2ban on to fast requests should fix this easily as the hashes dont actually take that long.
Re: How to Safely Store Your Users' Passwords in 2016
#156Serious question: What about using a Public/Private key encryption to store the password? - Private key is stored in a secure place. Offline for all i care; printed on a piece of paper; memorized and swallowed. - When user creates the account - password is padded with salt, then a public key is used to encrypt it. The resulting encrypted form is stored, along with the salt. - When user attempts to authenticate - the…
The more standard way to migrate passwords/authentication schemes is to do it on login. So if you want to switch to scrypt from some other format, wait for them to login, check their password via the old method, then rehash the password with the new method. Store in the database which method was used. If you're switching to a non-password based system like OAuth, make users link their accounts after logging in with t…
Thank you for your reply. Interesting you mention intercepting users passwords.
Our system already went through a similar transition years ago - when we had to migrate away from NDS (Novell), since we abandoned that technology.
In NDS we did not have access to hashes. We ended up having to "MTM" the passwords in opur web app to intercept them before they are sent to NDS and after a successful login store them in the database. To transition our entire user base took a very long time (more than a year), since we had no way to compel the users to login and had to wait until they login on their own volition.
Ever since we've been reluctant to lose the ability to recover the passwords. Transition to Active Directory has been on our agenda for quite some time - and having the ability to decrypt the password for this purpose - we can make that happen in short order (AD hashes the passwords, so it will be a one-way operation of course).
But the question still stands - is asymmetric encryption strong and secure enough to take place of hashing, assuming the private key is secured? I have not been able to find any relevant sources to answer these questions.
Re: How to Safely Store Your Users' Passwords in 2016
#157I called my bank the other day and they asked over the phone for my password. This isn't a bank I often use, I only currently have a loan through them so I've never used the login on the website. I said I don't remember setting a password. They gave me a hint about the characters in the password and I was able to remember the password based on their hint. I verbally said the password character by character and they c…
Same thing happened to me, my local credit union emailed me my password. They ensured me that they use "bank-level encryption". Of course I didn't get into the difference between one- and two-way encryption with the teller, or that email isn't secure.
We live in an age where this should be unacceptable. Why aren't there financial security laws yet?
Re: How to Safely Store Your Users' Passwords in 2016
#158It would be great if, in 2020, or sooner, but probably later, the answer is "don't use passwords any more. They are deprecated components of society."
Can you expand on this idea? What type of authentication method would replace it? (One that can't be directly linked to the person obviously).
Look at what Fido is doing [1] they have new Standards called UAF (Universal Authentification Factor) and U2F (Universal Second Factor). The idea is that you use some kind of local authenticator and then you sign a challange from the server with a private key that is embeded in the authenticator. The Authenticator can be Fingerprint Sensor, a extern device that you authenticate with a password or it could highjack the OS level login.
New Samsung phones and Lenovo Laptops already support this on the fingerprint sencor but the true benefit is that you can have competition among local authenticators without the server having to change anything.
For legacy devices where you do not have any kind of local authenticator their could be local software that lets you enter passwords. Its already part of the standard that the server has a way to only allow some of the authenticators, based on certification. This would allow a bank to specifiy only devices manufactured by a specific company or that have passed some certification process.
Now some people of course say that fingerprint sensors are not very secure. That is true. It still increases security because the local authenticator will only sign the challenge if it is sent from the correct website/software (App Id) and in most cases the TLS Channel Id. UAF (and/or U2F) prevent far more common attacks at the cost of less security if an attacker actually steels your phone. You can combine UAF with U2F for additional security even if your phone/laptop is stolen.
This has been passed to the W3C and its hopped FIDO 2.0 will be an offical standard [2] [3].
Google, Github and Dropbox already support U2F. PayPal supports UAF (works on mobile). Both of these can also work with NFC and Bluetooth LE.
[1] https://fidoalliance.org/specifications/overview/
[2] https://fidoalliance.org/fido-alliance-announces-fido-authen...
[3] https://www.w3.org/Submission/2015/SUBM-fido-web-api-2015112...
Re: How to Safely Store Your Users' Passwords in 2016
#159Earlier quoted context omitted.
I'm optimistic for the use of physical tokens instead of passwords. In my work environment, a lot of authentication is based on physical token possession plus a password just as a guard against lost devices (password validated by the token, not by the service). These kinds of systems aren't technically very complex but there hasn't been a lot of traction for them outside of corporate environments. The result is that…
I would love a replacement for passwords, but i dont think hardware based solutions are practical enough yet. It is a Gadget more i need to take with me, and even more make sure that it connects with any device i have. The worst part for me would be loosing that thing, in the end i would need alternative login methods anyway to be sure i dont lock myself out. Classic Authy on a Smartwatch would be the simplest method…
Its not one more Gadget that you have to carry around. New Lenovo Laptops and Samsung Phones already have UAF enabled Fingerprint Sensors that could be used for all your Web Authentification needs. The Yubikey is either the size of a USB slot or the size of a key on your keychain, so even your second factor is pretty minimal in size.
Alternative Login is always a problem, their is always a tradeoff between security and useability. You could easly print out some backup access codes. You can continue to use your E-Mail as a anker, you get an E-Mail and then your allowed to register a new token. That leaves the question of how does your E-Mail provider secure its login? I think Google is a good example of the options that are possible.
Re: How to Safely Store Your Users' Passwords in 2016
#160Lame title. Story talks about storing password hashes and not passwords. I'm still looking for a solution to storing actual user passwords. Scenario: All laptops in the company have a unique local administrator password. How do I manage this effectively as a domain admin?