191 reputation
4
bio website sweetsoftware.com
location
age
visits member for 2 years, 9 months
seen May 12 at 20:31

Software Developer (since childhood) and Electrical Engineer (don't you love the micro-hardware movements - Arduino and rPi). I've worked for NASA, built AI systems, compilers, and new computer languages, delved into cryptography and computer security, and am now building a fun mobile phone app for the fitness community.


Dec
25
awarded  Commentator
Dec
25
comment HMAC: How unique does a nonce need to be if the Date is also part of the signature?
Sorry, just realized I wrote one thing wrong there, should be: s-c: "Alice, Fs(PWD, nonce_c) = Answer_s, prove Fc, nonce_s". Note, Fs 2nd param should be nonce_c. However, the now corrected calculation is still an Oracle.
Dec
25
comment HMAC: How unique does a nonce need to be if the Date is also part of the signature?
@sebastiannielsen However, the server already gave me all the proof I need to run an off-line password attack, rate limits won't matter. c-s: "Hello, it's Alice, nonce_c, prove Fs", s-c: "Alice, Fs(PWD,nonce_s) = Answer_s, prove Fc, nonce_s". Client drops connection, attacks Answer_s offline. Rate limit didn't matter; this is the definition of an Oracle - accidentally provide more information than it should. We are now getting into the finer points of authentication protocol design. You should study Kerberos, ZKP, and SSL. Very cool protocols. They address these issues.
Dec
24
comment HMAC: How unique does a nonce need to be if the Date is also part of the signature?
You just made the server into a password Oracle. Now, I can generate challenges from rnd passwords, send them to the server and test the server's response until I get a response that matches my password. That is why the server must challenge the client first. Since anyone can challenge the server, then everyone can try a password guessing attack. There's no MITM attack with original algorithm posted above assuming the authentication algorithm generates a key for crypto and/or message signing. There is a password guessing attack possible for Eve, which is why Zero Knowledge Proofs are critical.
Dec
23
comment HMAC: How unique does a nonce need to be if the Date is also part of the signature?
On a more practical note, how do you propose to authenticate the server first?
Dec
23
comment Does too long a salt reduce the security of a stored password hash?
Because the cost of using the max salt length is also minimal compared to any potential future (unforeseen) problem or flaw. Why find out later you wish you had selected a choice that is the best you could have done, but didn't and compromised your system's (and users') security in some way. Selecting 64 bits may be practically the same as 128 or 160 or 256 based upon current knowledge, granted; however, algorithms always get easier to break, not harder. If the cost of storage/use is minimal, maxing salt entropy provides a level of insurance.
Dec
23
comment HMAC: How unique does a nonce need to be if the Date is also part of the signature?
@sebastiannielsen, apologies, but I'm confused. The objective of a properly built authn protocol is to produce a session key used to protect the channel. If the channel is not encrypted or signed (clear, but hashed), then that is a problem. In the common internet model, you might be thinking of SSL server-side only authentication with client password authn inside the SSL channel. However, this is a flawed authentication protocol as the server and client authns may be separated and attacked - a flaw in almost all current schemes. I stand by my statement; the familiar use case is insecure.
Dec
21
comment Does too long a salt reduce the security of a stored password hash?
@kasperd Fair enough - I shortened your answer a little bit. ;)
Dec
21
answered HMAC: How unique does a nonce need to be if the Date is also part of the signature?
Dec
21
awarded  Supporter
Dec
21
comment Does too long a salt reduce the security of a stored password hash?
Just use a Salt the length of the hash code, it matches the max entropy of the hash and the password. Longer Salts do no good. Why worry about the storage size of the salt column in your (no)SQL storage? Total salt bytes grows linear with the size of your user base, which, in any realistic working system should be small compared to the amount of data stored for each (all) users. Sizeof(Authentication Data) << Sizeof(All other System Data).
Dec
21
comment Does too long a salt reduce the security of a stored password hash?
A monotonically increasing sequence is guaranteed to be globally unique (1, 2, 3, ...). I don't think this is the "only property" that's important. Use a randomly generated Salt the same length as the password hash and you're highly likely to not only have a system-wide unique salt, but a world wide unique salt.
Dec
21
comment Does too long a salt reduce the security of a stored password hash?
Why stop at 16 hex? That's only 64 bits of entropy for the salt and low enough to encounter some salt repeats, however, unlikely. Just set Salt Length to the same length as the hash output. Longer salts have no more entropy, by definition, shorter salts have less entropy, less effective. Finally, storage cannot be an issue. Whatever the s/w is doing, it requires more storage than some simple old user authentication bits.
Sep
24
awarded  Autobiographer
Oct
8
awarded  Teacher
Oct
8
answered create a variants of MD5