141–150 of 321 posts
I 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…
I 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…
Seems that they don't have any other way to grant the technicians access to the server/my account, which is absolutely ridiculous.
Earlier quoted context omitted.
I think the idea is that the scrypt hash does become the password, but it's a better password. A password with a lot more entropy (kinda). The increased kinda-sorta entropy makes the use of a slow key derivation function on the server side unnecessary, so SHA-256 becomes sufficient. Not sure how I feel about it.
I feel that this is needlessly dangerous, personally. How are the salts managed? This detail is important. SHA256(scrypt(password, constant_value_instead_of_salt)) is going to produce collisions in the stored hash.
I think it's dangerous because of the dependence on the client, and useless because scrypt(password,salt,work_factor) on the server is plenty hard to attack.
Earlier 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…
I think the idea is that the scrypt hash does become the password, but it's a better password. A password with a lot more entropy (kinda). The increased kinda-sorta entropy makes the use of a slow key derivation function on the server side unnecessary, so SHA-256 becomes sufficient. Not sure how I feel about it.
Earlier quoted context omitted.
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…
>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. I don't even your threat model. Can you walk us through how you see this working? Client takes 'crappypassword' as input, sends p = scrypt('crappypassword') The server stores SHA256(p)? EDIT: misread w…
Earlier quoted context omitted.
I feel that this is needlessly dangerous, personally. How are the salts managed? This detail is important. SHA256(scrypt(password, constant_value_instead_of_salt)) is going to produce collisions in the stored hash.
I think he's going for SHA256(scrypt(password, salt, work_factor)) and saying the bare SHA256 is sufficient. As opposed to SHA256(salt+scrypt(password, salt, work_factor)). I think it's dangerous because of the dependence on the client, and useless because scrypt(password,salt,work_factor) on the server is plenty hard to attack.
It enables DoS attacks, though, right?
It 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).
I don't have a solution myself, but I hope there is one some day.
Earlier quoted context omitted.
I don't think you should out them publicly. Are you interested in having them improve their security model [1] or do you want to have what they have they done out in the open so that others can try to social engineer them and their customers might suffer the consequences? [1] If so, tell them about this in a way that will get their attention without causing their customers or them any harm.
You're correct. I'll contact them.
Earlier quoted context omitted.
>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. I don't even your threat model. Can you walk us through how you see this working? Client takes 'crappypassword' as input, sends p = scrypt('crappypassword') The server stores SHA256(p)? EDIT: misread w…
Yes, now it's correct.
Otherwise, you're relying on the user side to properly safeguard bcrypted password. That is often wrong. You cannot store any kind of transformed password anywhere, or it's no longer a password, but a token.
Yes, those "Remember me" things transform passwords into tokens. Tokens can be stolen.
- 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 password that is provided is padded with the stored salt, encrypted with the public key and compared to the stored password.
Private key is never used when comparing passwords. Never available to the system doing authentication, etc.
The only purpose of using a reversible encryption - is to be able to switch to a different authentication provider completely transparently to the user.
I've implemented this functionality considering that we may need to switch over to active directory (or some other directory) in place of storing passwords in the database - but never used it, fearful that i would be committing some cardinal crime against proper security practices
Thoughts?