874 reputation
11124
bio website
location
age
visits member for 3 years, 3 months
seen Jul 29 at 7:26

Aug
12
comment Signed request vs HTTP digest auth for API authentication?
You are right this is complicated and messy. And the log will probably be so big. SSL it is.
Aug
12
asked Is it okay for API secret to be stored in plain text or decrypt-able?
Aug
12
comment Signed request vs HTTP digest auth for API authentication?
Purely scientific purposes, SSL is cheap anyway but this is just for kicks.
Aug
12
comment Signed request vs HTTP digest auth for API authentication?
@curiousguy Well how can you do that since either methods require you know the API secret first right? And the API secret is not transmitted in plain sight even without SSL.
Aug
12
comment Signed request vs HTTP digest auth for API authentication?
Are there other means of protecting agaist request replay other than SSL?
Aug
12
comment Signed request vs HTTP digest auth for API authentication?
@curiousguy Well we can but for this example we don't really need to encrypt the whole HTTP traffic just the credentials.
Aug
12
accepted Can /etc/passwd file be accessed on a cpanel shared hosting account?
Aug
12
accepted What was done to gain a list of home directory accounts?
Aug
12
accepted Is it okay to wrap a cryptographic hash with MD5 for storage?
Aug
12
asked Signed request vs HTTP digest auth for API authentication?
Aug
11
comment Does truncating the cryptographic hash make it impossible to crack?
Well it's not exactly "once" since in the first time you see the hash you can't tell at once if it was truncated and how many was truncated. If you are implying you have to make your software guess many times at "once" then yes I agree.
Aug
9
comment Does truncating the cryptographic hash make it impossible to crack?
Well that's the goal, to make the software/human assume and do more "thinking" therefore making it extra harder to crack.
Aug
9
comment Does truncating the cryptographic hash make it impossible to crack?
The assumption is the cracking software don't know it's truncated. Or if it knew, it doesn't know what was truncated.
Aug
9
comment Does truncating the cryptographic hash make it impossible to crack?
@B-Con By this time I now understand truncating too many is not a good idea since it's likely to cause collision. So my question now is, since truncation has it's (arguable) benefits (since Google does it according to Rook's answer below), how many truncation is the maximum we can do so that it won't be prone to collision.
Aug
9
comment Does truncating the cryptographic hash make it impossible to crack?
@B-Con Honestly I don't quite understand what the prefix and suffix of (n-m) means. I think it's better if the question was not "too" technical :-)
Aug
9
comment Does truncating the cryptographic hash make it impossible to crack?
Proper salts meaning unique per user, random, at least 20 characters right?
Aug
9
comment Does truncating the cryptographic hash make it impossible to crack?
I do agree that truncating "too many" characters makes you vulnerable to other passwords but given you have unique salt and iterations do you still not recommend truncating? Wouldn't truncating 2 or 3 characters protect you from dictionary/rainbow attacks since if the hash ever matches something the original value will never be known?
Aug
9
comment Does truncating the cryptographic hash make it impossible to crack?
Regarding caution, as stated in the question "along with salts, iterations, etc." :-)
Aug
9
comment Does truncating the cryptographic hash make it impossible to crack?
Agree, I guess it depends on how many characters I truncate? The chance of collision with a different password is probably very tiny if I just truncate say 2 or 3 characters right?
Aug
9
comment Is it okay to wrap a cryptographic hash with MD5 for storage?
Agree, the only reason I chose md5 is it returns 32 bytes vs sha1 which is 40 or sha256 which is 64. But I think I will use sha256 instead then truncate.