Timeline for Are there vunerabilities with this authentication mechanism?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 10, 2012 at 9:51 | comment | added | symcbean | @James: if the client is a browser, then the code used to generate the hash is sent as cleartext javascript and can hence be modified | |
| Jul 6, 2012 at 18:44 | comment | added | curiousguy | "If you're talking about a browser as the client" The question was not explicit about the context (generic client/browser vs. specialized client), but James latter explained he was talking about a mobile app, so this particular concern does not apply in his case. But still, it is an important remark. | |
| Jul 5, 2012 at 18:04 | comment | added | James | @curiousguy yeah that was a misunderstanding on my part. | |
| Jul 5, 2012 at 17:33 | comment | added | curiousguy | @James "If the salt is intercepted & modified at step 2," who said the salt would be modified? "If the salt is high-entropy e.g. 16+ bytes, surely this would practically nullify the chances of it being cracked in any reasonable amount of time?" entropy? what are you talking about? The salt is sent in clear. It is constant for a given user, and known by the attacker (who can listen to packets on the wire, by hypothesis). The entropy of the salt is zero. | |
| Jul 5, 2012 at 15:13 | comment | added | James | If the salt is intercepted & modified at step 2, surely this would simply mean that when the token comes back to the server the hash values won't match and the server would reject (as the salt has changed). Also, I don't see how the original password could be revealed (unless you are referring to brute-force attack). If the salt is high-entropy e.g. 16+ bytes, surely this would practically nullify the chances of it being cracked in any reasonable amount of time? | |
| Jul 5, 2012 at 14:54 | history | answered | symcbean | CC BY-SA 3.0 |