"It's the theodicy of price, quality, and speed (pick two)"
You guys always act as this is some kind of law of nature or something. By now, it's just a saying, and sayings may capture some common sense in some situations, but they carry very little weight in any argument.
On the other hand, I don't like smartphones. I carry a small, shitty, Nokia 1208 cellphone. It's light, small, tough, and has a huge battery life. The battery is very easily replaced, and I carry with me a spare fully loaded battery. Many people that I work with have iphones. Most of the time, when I go down to just 1-2 bars, iphones are already completely out of signal. Example, at the elevator, every iphone user drops the call immediately, but I still keep enough signal to continue talking. That's what a cellphone is supposed to be. I don't feel the urge to carry with me a camera, a digital recorder, an audio/video player, a web browser, etc. with me at all times, but if I did, I would carry a separate device that would do all of those things, while still carrying my small, simple phone that always works.
I did as well, but now I simply don't want to go back to a life without instant weather radar, email, maps, news services, instant train delay info, calendar, synced contact list, wifi signal, laptop modem, wikipedia, usable SMS and slashdot as RSS feed directly synced to my phone. Oh, and battery life and call quality are certainly up to par, and calling anybody with it is really easy. The fact that newer phones can charge of any micro-USB connection makes that I'm really never without a charger anyway.
Then again, I've bought the HTC Hero phone, not an iPhone. This must be one of the most nice phones out there. If required, I bought an extended battery for it as well (but haven't used it yet, I just put it on a charger once in two days).
You may have dry hands, while others have moist hands that more easily can short with the antenna? With my hands, I'm sure not to have this problem; they are dry enough not to work on many capacitive fingerprint readers (although, somehow, my Hero does fine - great touch screen that).
Yeah, and did you see the danger level of those protesters? That's the whole draw back of these kind of technologies. It's even more scary as this device can permanently damage hearing.
I've seen tasers used against persons that just stood in the middle of a road and didn't want to move. The infotainment made it absolutely clear that they cheered this kind of use of tasers.
Depends on where you do the hashing. If you do it on the client then you will just generate the hashes by starting with the first byte (00, 01, 02 hex until you find the correct one). Then the second byte etc. In total, you'll have to try and find 20 bytes (taking that you are using SHA-1 for the hash). For each byte you will find the correct answer after 128 statistical test average. So that's just 2560 statistical tests total. Say that you have to use 100 tests to get to each byte value, then you have 256000 tests total to crack the hash instead of the password. This is way too low.
Of course, you can also hash the password on the server, but then you would still have to send the plain password, which is not a good idea anyway, even when using SSL. The way around this has of course already been discussed, and is bad practice. It's applying a salt to each password before hashing it and sending it from the client.
ON MODERN CPU'S THAT ARE RUNNING A COMPLETE WEB-SERVICE, YOU DON'T CARE, NOT EVEN ABOUT THE FUCKING CONTEXT SWITCH. 1990 CALLING, THEY WANT THEIR ASSEMBLY LEVEL OPTIMIZATIONS BACK.
Yea gods, does this hole thread consists or idiots or what?
Of course I won't attack your SSL figures (even though they don't include the reference system info, but whatever). Of course, that does not make the GP incorrect in stating that the comparing of the full string will use less cycles. It also leaves out the call to the openssl library, which is probably more costly than the actual hashing of a small string (and salt).
The problem is that the AC is mixing a completely sensible solution (using hashes - introduced by betterunixthanunix nonetheless) to argue a completely idiot point (the amount of CPU power required to fully check passwords). The discussion can only go downwards from there.
Are you actually talking about the CPU time of comparing a 16 character string? Do you want to have the times for my 25 year old MSX computer or my 4 core CPU? And YOU are complaining about a Strawmen argument? Are you out of your mind?
Mods, don't mod this kind of thing insightful, even though the hashing is good advice.
It hasn't been broken yet for this kind of purpose, but I would go and recommend SHA-2 256 for new protocols, as there is a chance that new attacks may translate to new attacks on SHA-1. SHA-2 is based on similar principles, but it is certainly more complex to crack. Basically many "broken" hash algorithms can still be used for key derivation, password protection (basically any scheme that poses severe restrictions on the input). It is of course much safer not to rely on broken hash functions at all.
It seems that it is more and more feasible to do time based attacks even over something like the internet. It becomes even easier if such applications are ported over for use in corporate intranet environments of course. Firewalls can be fooled, e.g. by using multiple IP addresses quite easily. It is not very smart (and even dangerous) to rely on other security protection mechanisms if you can quite easily fix it in the application itself anyway.
So don't think that time based attacks are only feasible if you've got the hardware in your hands. They are not, they may not even be harder for the attacker who can simply rely on automation and a good statistical library to do the hard work.
If the library is not using a salt, you can still retrieve the value of the hash using the exact same method. Furthermore, if the hash is intercepted they can use it for looking up the password in a rainbow table or similar. Just hashing is not enough.
That's what you get from using an outdated college lecture as starting point. Of course, as already mentioned in the responses, the correct way is to have a full length random salt, XOR the password in it (in case the RNG is broken, possibly use an additional counter or something), hash it and then send the salt & hash to the other side. Sending the password in plain or relying just on SSL is a stupid idea for an online system.
Slashdot Mirror
It is only flooded with it if you cannot wade through it, and you can.
"It's the theodicy of price, quality, and speed (pick two)"
You guys always act as this is some kind of law of nature or something. By now, it's just a saying, and sayings may capture some common sense in some situations, but they carry very little weight in any argument.
eh [thinking of a non-sentence to put more weight to my non-argument].
Did you notice that strawman arguments almost always come from A/C's?
I'm just .
On the other hand, I don't like smartphones. I carry a small, shitty, Nokia 1208 cellphone. It's light, small, tough, and has a huge battery life. The battery is very easily replaced, and I carry with me a spare fully loaded battery. Many people that I work with have iphones. Most of the time, when I go down to just 1-2 bars, iphones are already completely out of signal. Example, at the elevator, every iphone user drops the call immediately, but I still keep enough signal to continue talking. That's what a cellphone is supposed to be. I don't feel the urge to carry with me a camera, a digital recorder, an audio/video player, a web browser, etc. with me at all times, but if I did, I would carry a separate device that would do all of those things, while still carrying my small, simple phone that always works.
I did as well, but now I simply don't want to go back to a life without instant weather radar, email, maps, news services, instant train delay info, calendar, synced contact list, wifi signal, laptop modem, wikipedia, usable SMS and slashdot as RSS feed directly synced to my phone. Oh, and battery life and call quality are certainly up to par, and calling anybody with it is really easy. The fact that newer phones can charge of any micro-USB connection makes that I'm really never without a charger anyway.
Then again, I've bought the HTC Hero phone, not an iPhone. This must be one of the most nice phones out there. If required, I bought an extended battery for it as well (but haven't used it yet, I just put it on a charger once in two days).
So, it's more like a death gripe than a death grip? Sorry, it's the whine...
Oh, man, you have no idea what *their* Mercedeses looked like.
You may have dry hands, while others have moist hands that more easily can short with the antenna? With my hands, I'm sure not to have this problem; they are dry enough not to work on many capacitive fingerprint readers (although, somehow, my Hero does fine - great touch screen that).
... and is it stable?
"It appears some readers (and readers with mod points) have a case of the Mondays today..."
Ok, what ever was said before, this comment should get you modded straight into hell.
It was funny in the film because it is not funny at all.
Yeah, and did you see the danger level of those protesters? That's the whole draw back of these kind of technologies. It's even more scary as this device can permanently damage hearing.
I've seen tasers used against persons that just stood in the middle of a road and didn't want to move. The infotainment made it absolutely clear that they cheered this kind of use of tasers.
And that compares to a 16 character string compare, how?
Ah, that could well be, thanks for the correction. My memory is starting to get a bit murky on the details after 15+ years :)
Depends on where you do the hashing. If you do it on the client then you will just generate the hashes by starting with the first byte (00, 01, 02 hex until you find the correct one). Then the second byte etc. In total, you'll have to try and find 20 bytes (taking that you are using SHA-1 for the hash). For each byte you will find the correct answer after 128 statistical test average. So that's just 2560 statistical tests total. Say that you have to use 100 tests to get to each byte value, then you have 256000 tests total to crack the hash instead of the password. This is way too low.
Of course, you can also hash the password on the server, but then you would still have to send the plain password, which is not a good idea anyway, even when using SSL. The way around this has of course already been discussed, and is bad practice. It's applying a salt to each password before hashing it and sending it from the client.
ON MODERN CPU'S THAT ARE RUNNING A COMPLETE WEB-SERVICE, YOU DON'T CARE, NOT EVEN ABOUT THE FUCKING CONTEXT SWITCH. 1990 CALLING, THEY WANT THEIR ASSEMBLY LEVEL OPTIMIZATIONS BACK.
Yea gods, does this hole thread consists or idiots or what?
Oh, those interesting discussions when trying to calculate the time for comparing two strings.
We're here in 2010! Half an XML tag will take 10 times more time than comparing two string of 16 characters long (if that).
The AC is wrong alright. He's wrong for even brining it up.
Of course I won't attack your SSL figures (even though they don't include the reference system info, but whatever). Of course, that does not make the GP incorrect in stating that the comparing of the full string will use less cycles. It also leaves out the call to the openssl library, which is probably more costly than the actual hashing of a small string (and salt).
The problem is that the AC is mixing a completely sensible solution (using hashes - introduced by betterunixthanunix nonetheless) to argue a completely idiot point (the amount of CPU power required to fully check passwords). The discussion can only go downwards from there.
Are you actually talking about the CPU time of comparing a 16 character string? Do you want to have the times for my 25 year old MSX computer or my 4 core CPU? And YOU are complaining about a Strawmen argument? Are you out of your mind?
Mods, don't mod this kind of thing insightful, even though the hashing is good advice.
Although I agree with your stance (I think, it's starting to get confusing what you are both arguing) I don't think it was wise using the word troll.
OTOH, moderators, that does not give you the right to mod him flamebait.
Don't worry about it, it's nice to see people make the case for the GiB notation unknowingly :)
It hasn't been broken yet for this kind of purpose, but I would go and recommend SHA-2 256 for new protocols, as there is a chance that new attacks may translate to new attacks on SHA-1. SHA-2 is based on similar principles, but it is certainly more complex to crack. Basically many "broken" hash algorithms can still be used for key derivation, password protection (basically any scheme that poses severe restrictions on the input). It is of course much safer not to rely on broken hash functions at all.
Glad it is just gamma rays, if it were in infrared or even visible light, somebody would probably blame the burst for the global temperature rise.
It seems that it is more and more feasible to do time based attacks even over something like the internet. It becomes even easier if such applications are ported over for use in corporate intranet environments of course. Firewalls can be fooled, e.g. by using multiple IP addresses quite easily. It is not very smart (and even dangerous) to rely on other security protection mechanisms if you can quite easily fix it in the application itself anyway.
So don't think that time based attacks are only feasible if you've got the hardware in your hands. They are not, they may not even be harder for the attacker who can simply rely on automation and a good statistical library to do the hard work.
If the library is not using a salt, you can still retrieve the value of the hash using the exact same method. Furthermore, if the hash is intercepted they can use it for looking up the password in a rainbow table or similar. Just hashing is not enough.
That's what you get from using an outdated college lecture as starting point. Of course, as already mentioned in the responses, the correct way is to have a full length random salt, XOR the password in it (in case the RNG is broken, possibly use an additional counter or something), hash it and then send the salt & hash to the other side. Sending the password in plain or relying just on SSL is a stupid idea for an online system.