Re: [cryptography] Javascript Password Hashing: Scrypt with WebCrypto API?
On Mar 13, 2015, at 8:43 AM, Solar Designer so...@openwall.com wrote: On Thu, Mar 12, 2015 at 10:57:47AM -0600, Jeffrey Goldberg wrote: 2. Use SHA-512 in PBKDF2 This will make PBKDF2 resistant to GPU based cracking efforts. Note that this is resistance to attacks using current, off-the-shelf, hardware. It is only a short term solution. I think this wording is too strong. While I did and I continue to advocate SHA-512 over SHA-256 for this reason (when someone insists on PBKDF2 or the like anyway), the gap with recent attack implementations is narrower than it used to be. Ah, so the term of this “short term solution” is already expiring. For sha512crypt vs. sha256crypt, it's down to ~2x: https://hashcat.net/misc/p130_img/changes_v130.png Interesting. Thank you for that, Solar. And scrypt even at fairly low settings is likely somewhat stronger (or rather not-as-weak) against GPU attacks than PBKDF2-HMAC-SHA-512 at comparable low running time. Not at settings as low as Litecoin's 128 KB with r=1, but at settings like 2 MB with r=8, which is affordable in JavaScript. OK. So I guess we return to the original question, does anyone know of an scrypt implementation in JavaScript? BTW, given the wide availability of scrypt altcoin ASICs, some of which can handle higher N (this is known) but likely not higher r (this is a plausible guess, given the incentive model for those ASICs), and given the effect r has on scrypt speeds on GPU, I recommend that scrypt paper's recommended r=8 (rather than altcoins' typical r=1) be used. That's even when the original reason for using r=8 (reducing the frequency and thus performance impact of TLB misses, and allowing for some prefetching) does not apply, like it mostly does not with JavaScript. Thanks! (Of course, someone may produce more capable scrypt ASICs.) Indeed. As I said, in this race the attacker has more to gain from Moore’s Law than the defender. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SRP 6a + storage of password's related material strength?
On 3/13/15 3:11 PM, Solar Designer wrote: Because SRP protocol is cool, but i'm really wondering if the default methods are strong enough against bruteforcing. They are not. That was my concern. Does anyone ever tried to make SRP authentication protocol extensions/specs to work with server-side storage of hashes based on scrypt? From my umble understanding of crypto, it would be like leveraging the best properties of SRP authentication protocol and scrypt password hashing. But yet, my poor-math brain have difficulties understanding if that's feasible or it's just a stupid consideration. Fabio ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Javascript Password Hashing: Scrypt with WebCrypto API?
On Fri, Mar 13, 2015 at 12:29:58PM -0600, Jeffrey Goldberg wrote: OK. So I guess we return to the original question, does anyone know of an scrypt implementation in JavaScript? They've already been posted. But unlike Alexander who was kind enough to repeat himself, I won't give any further encouragement to folly. Stop. Really: stop. Client-side-in-browser JavaScript crypto does not and cannot provide security. Like building a castle from jello, it is flawed in conception. -- . ___ ___ . . ___ . \/ |\ |\ \ . _\_ /__ |-\ |-\ \__ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Javascript Password Hashing: Scrypt with WebCrypto API?
On Fri, Mar 13, 2015 at 12:29:58PM -0600, Jeffrey Goldberg wrote: OK. So I guess we return to the original question, does anyone know of an scrypt implementation in JavaScript? I had already posted these links: https://github.com/dchest/scrypt-async-js http://dchest.github.io/scrypt-async-js/demo.html Alexander ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] SRP 6a + storage of password's related material strength?
Hi all, SRP is a very cool authentication protocol, not yet widely deployed, but with very interesting properties. I'm wondering how strong is considered the storage of the password's related material strength? I mean, from a passive/offline brute forcing perspective, how can be compared scrypt vs. SRP's server-side storage of passwords? Does anyone ever considered that kind of problem? Because SRP protocol is cool, but i'm really wondering if the default methods are strong enough against bruteforcing. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Javascript Password Hashing: Scrypt with WebCrypto API?
I agree with Jeffrey's suggestion to implement server-side KDF as well, with higher settings. Just some minor detail on what (little) can be done on client side in JavaScript: On Thu, Mar 12, 2015 at 10:57:47AM -0600, Jeffrey Goldberg wrote: 2. Use SHA-512 in PBKDF2 This will make PBKDF2 resistant to GPU based cracking efforts. Note that this is resistance to attacks using current, off-the-shelf, hardware. It is only a short term solution. I think this wording is too strong. While I did and I continue to advocate SHA-512 over SHA-256 for this reason (when someone insists on PBKDF2 or the like anyway), the gap with recent attack implementations is narrower than it used to be. For sha512crypt vs. sha256crypt, it's down to ~2x: https://hashcat.net/misc/p130_img/changes_v130.png And scrypt even at fairly low settings is likely somewhat stronger (or rather not-as-weak) against GPU attacks than PBKDF2-HMAC-SHA-512 at comparable low running time. Not at settings as low as Litecoin's 128 KB with r=1, but at settings like 2 MB with r=8, which is affordable in JavaScript. BTW, given the wide availability of scrypt altcoin ASICs, some of which can handle higher N (this is known) but likely not higher r (this is a plausible guess, given the incentive model for those ASICs), and given the effect r has on scrypt speeds on GPU, I recommend that scrypt paper's recommended r=8 (rather than altcoins' typical r=1) be used. That's even when the original reason for using r=8 (reducing the frequency and thus performance impact of TLB misses, and allowing for some prefetching) does not apply, like it mostly does not with JavaScript. (Of course, someone may produce more capable scrypt ASICs.) Alexander ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SRP 6a + storage of password's related material strength?
On Fri, Mar 13, 2015 at 9:25 AM, Fabio Pietrosanti (naif) - lists
li...@infosecurity.ch wrote:
Hi all,
SRP is a very cool authentication protocol, not yet widely deployed, but
with very interesting properties.
I'm wondering how strong is considered the storage of the password's
related material strength?
I mean, from a passive/offline brute forcing perspective, how can be
compared scrypt vs. SRP's server-side storage of passwords?
Does anyone ever considered that kind of problem?
Because SRP protocol is cool, but i'm really wondering if the default
methods are strong enough against bruteforcing.
scrypt Vs. SRP? There is no such dilemma, as they serve different
purposes. The reality is that you should use your password hashing
scheme of choice --- say scrypt --- *and*, if you want to get rid of
the X.509 PKI business, your PAKE protocol of choice --- say SRP 6a
--- to provide mutual authentication.
Yet, you need to be very careful if you adopt SRP:
If an attacker learns a user's SRP verifier (e.g., by gaining access
to a server's password file), the attacker can masquerade as the real
server to that user, and can also attempt a dictionary attack to
recover that user's password. [RFC5054]
The cost of a password recovery attack against the SRP password
verifier (i.e., preimage security) will dependent on the known attacks
to the hashing scheme used to instantiate the SRP protocol. More
specifically, if the hashing scheme is a simple hash function, offline
dictionary attacks will be easy to mount and you will get no security
whatsoever. Still, if the (password) hashing scheme provides better
security guarantees (e.g., scrypt) the final construction will benefit
from its adoption.
In fact: as long as the password verifier remains opaque to the
server, it is possible to retain some freedom of choice for the
hashing scheme used client-slide (i.e., the client computes x =
scrypt(passphrase,salt,C,password,dkLen) and v = g^x mod N and the
server stores {I,salt,v}, where I the user identity, salt is the
user's salt, and v the password verifier).
At the same time, replacing a cryptographic hash function with a
password-based KDF makes the overall password-management harder and
impacts the UX...
Take care.
[RFC5054] http://www.ietf.org/rfc/rfc5054.txt
-- Alfonso
tweets @secYOUre
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SRP 6a + storage of password's related material strength?
On Fri, Mar 13, 2015 at 10:25:11AM +0100, Fabio Pietrosanti (naif) - lists wrote: SRP is a very cool authentication protocol, not yet widely deployed, but with very interesting properties. I'm wondering how strong is considered the storage of the password's related material strength? I mean, from a passive/offline brute forcing perspective, how can be compared scrypt vs. SRP's server-side storage of passwords? scrypt focuses on addressing this very problem. SRP does not. Does anyone ever considered that kind of problem? Yes: https://twitter.com/JokFP/status/234074891408793600 http://opine.me/blizzards-battle-net-hack/ http://opine.me/srp-to-sha1/ Because SRP protocol is cool, but i'm really wondering if the default methods are strong enough against bruteforcing. They are not. Alexander ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SRP 6a + storage of password's related material strength?
On Mar 13, 2015, at 3:25 AM, Fabio Pietrosanti (naif) - lists li...@infosecurity.ch wrote: SRP is a very cool authentication protocol, not yet widely deployed, but with very interesting properties. Indeed it is. I'm wondering how strong is considered the storage of the password's related material strength? As others have said, these are separate properties. SRP is a independent of the KDF. It does not solve or address the problem of password cracking. I mean, from a passive/offline brute forcing perspective, how can be compared scrypt vs. SRP's server-side storage of passwords? As others have said, this is like comparing AES with PBKDF2. They address different problems. Does anyone ever considered that kind of problem? Yes. I have, but nothing written up yet. One (of several) advantages of SRP is that the password is never sent as plaintext to the server. Thus, it reduces the scope of the server from capturing the password. So it makes it harder for the server to “be evil”. So this may still a worth while thing for you to pursue, even if it does’t solve the fact that you are storing stuff that needs to be kept secret because it can be cracked. Also note, that if you are delivering the SRP routines to the client in a web browser, then this gains you nothing. As a compromised server could just deliver malicious JavaScript. That is, your delivery system is vulnerable to the same attacks that you are trying to defend against by using SRP. Because SRP protocol is cool, but i'm really wondering if the default methods are strong enough against brute forcing. Forgive the repetition of what I and others have said: SRP has nothing to say about brute forcing. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
