4 ms·

For websites/apps this is true. There's already a straightfoward solution (which you point to): store passwords with bcrypt (or scrypt) and use HTTPS for all pa

by delano 16y ago

For websites/apps this is true. There's already a straightfoward solution (which you point to): store passwords with bcrypt (or scrypt) and use HTTPS for all pages that send/receive the session cookie. For authentication APIs, it's less clear. The default right now seems to be basic or digest auth + HTTPS. There's also OAuth but it's a mess to implement/integrate with. I personally like the Amazon Web Services approach with signed requests. It's helpful to separate the two usecases because they are very different.

tptacek 16y ago
The difference between OAuth and Javascript SRP (what AUTHO.ME implements) is that OAuth does the crypto (what little there is of it) serverside, and AUTHO.ME does the crypto (crypto of the most intense and fragile kind) clientside. This isn't a small difference.
- delano 16y ago
  That's good to know. I just wanted to separate the two usecases from the developer's perspective. I'm not qualified to make any authoritative conclusions about any particular solution.
  - zedshaw 16y ago
    Actually, he's incorrect. The crypto is calculated in javascript, and in a C library written by the author of SRP: http://srp.stanford.edu/download.html http://srp.stanford.edu/download.html I'm using 2.1.2 with one slight modification to use SHA256 instead of SHA1+MGF1. That means that, should there be a failure in the javascript, it has a chance of getting caught in the C code written by the author of SRP.
    - tptacek 16y ago
      I'm not incorrect. I did actually read your code, Zed. You think I've made a claim that I haven't made: that you wrote a serverside implementation of SRP. I know you're using the original SRP library. That was a good call. You know SRP is mutual auth, right?
      - zedshaw 16y ago
        Yes, I do, but claiming I wrote the crypto in javascript is false. I wrote one part in javascript, and the other part is in C. That means, if there's an attack against the Javascript cryptography not the browser environment, then the mutual aspect of the cryptography will mean that the C side will catch the error. That's why you're wrong when you say I did in javascript. Only 1/2 of it is in javascript, and I only wrote a minimal amount of that.
- zedshaw 16y ago
  Again, if there's an actual demonstration of Javscript maths calculating incorrectly, then please give it. I'd like to make sure it's covered in the SJCL. Otherwise, this claim basically says that Javascript is either not turing complete or doesn't have math sufficient to do the crypto, yet the SJCL does it. It also assumes that other languages somehow have "magic" math, when really nearly all cryptography is giant bignum hacks that exploit how binary math works. If you've got a counter to this, then by all means, I'd like to see it.
  - tptacek 16y ago
    "Turing completeness" does not mean "safe environment in which to run cryptography". There are in fact math problems in Javascript environments, but they are far from the worst problems you face there.
    - zedshaw 16y ago
      Again, you say javascript cryptography is flawed, and then say it's a browser environment problem. Let's break this down. If the flaw is in how javascript does math, then that's something Autho.me has to deal with and I'd like to know about it. If however, this is a flaw in browser environment, then all methods that use a browser are equally flawed. That includes OpenID, Oauth, SRP, and your own proposed solution of bcrypt. That's because, once I can exploit the browser environment, then I have access to anything the user submits. That's the crux of my question: If you say there's an exploit against cryptography because of javascript math then demonstrate it. If you have exploits against the browser environment, then I can't fix those and they apply to your proposed solutions. Let's take an example: An attacker can inject XSS code onto the login page and get the SRP password. Well, an attacker that can XSS the login page and get the password from your SSL/bcrypt solution. They've got access to the whole page. So, if you find demos of failed math in javascript I'd like to see those.
      - tptacek 16y ago
        Look, I'm just not wading into this. You and I should, as much as possible, avoid arguing; because of our personality types, we're just going to end up at the nerd equivalent of pistols at dawn. You're telling people to use SSL with this. That is good. With SSL in the mix, my only real issue with AUTHO.ME is that it's a lot of moving parts for (what I think is) minimal value. You think "not having to implement bcrypt or PBKDF2" is major value. Guess what: this point is not worth a huge argument. And it's absolutely not worth a line-by-line evaluation of your crypto code, so I'm just not going to do it. If you're planning on a doing an indie two-factor auth project, that value may be less minimal. I have no coherent opinion that stuff. Good luck with it. If you do something crazy, I'll call you on it, which is I think what you want. Ignore Kaminsky, by the way. I can't imagine how using RSA instead of SRP could possibly make this safer, but I can imagine lots of ways in which it could make you much less safe.

by delano 16y ago

tptacek 16y ago

The difference between OAuth and Javascript SRP (what AUTHO.ME implements) is that OAuth does the crypto (what little there is of it) serverside, and AUTHO.ME does the crypto (crypto of the most intense and fragile kind) clientside. This isn't a small difference.

delano 16y ago
That's good to know. I just wanted to separate the two usecases from the developer's perspective. I'm not qualified to make any authoritative conclusions about any particular solution.
- zedshaw 16y ago
  Actually, he's incorrect. The crypto is calculated in javascript, and in a C library written by the author of SRP: http://srp.stanford.edu/download.html http://srp.stanford.edu/download.html I'm using 2.1.2 with one slight modification to use SHA256 instead of SHA1+MGF1. That means that, should there be a failure in the javascript, it has a chance of getting caught in the C code written by the author of SRP.
  - tptacek 16y ago
    I'm not incorrect. I did actually read your code, Zed. You think I've made a claim that I haven't made: that you wrote a serverside implementation of SRP. I know you're using the original SRP library. That was a good call. You know SRP is mutual auth, right?
    - zedshaw 16y ago
      Yes, I do, but claiming I wrote the crypto in javascript is false. I wrote one part in javascript, and the other part is in C. That means, if there's an attack against the Javascript cryptography not the browser environment, then the mutual aspect of the cryptography will mean that the C side will catch the error. That's why you're wrong when you say I did in javascript. Only 1/2 of it is in javascript, and I only wrote a minimal amount of that.
zedshaw 16y ago
Again, if there's an actual demonstration of Javscript maths calculating incorrectly, then please give it. I'd like to make sure it's covered in the SJCL. Otherwise, this claim basically says that Javascript is either not turing complete or doesn't have math sufficient to do the crypto, yet the SJCL does it. It also assumes that other languages somehow have "magic" math, when really nearly all cryptography is giant bignum hacks that exploit how binary math works. If you've got a counter to this, then by all means, I'd like to see it.
- tptacek 16y ago
  "Turing completeness" does not mean "safe environment in which to run cryptography". There are in fact math problems in Javascript environments, but they are far from the worst problems you face there.
  - zedshaw 16y ago
    Again, you say javascript cryptography is flawed, and then say it's a browser environment problem. Let's break this down. If the flaw is in how javascript does math, then that's something Autho.me has to deal with and I'd like to know about it. If however, this is a flaw in browser environment, then all methods that use a browser are equally flawed. That includes OpenID, Oauth, SRP, and your own proposed solution of bcrypt. That's because, once I can exploit the browser environment, then I have access to anything the user submits. That's the crux of my question: If you say there's an exploit against cryptography because of javascript math then demonstrate it. If you have exploits against the browser environment, then I can't fix those and they apply to your proposed solutions. Let's take an example: An attacker can inject XSS code onto the login page and get the SRP password. Well, an attacker that can XSS the login page and get the password from your SSL/bcrypt solution. They've got access to the whole page. So, if you find demos of failed math in javascript I'd like to see those.
    - tptacek 16y ago
      Look, I'm just not wading into this. You and I should, as much as possible, avoid arguing; because of our personality types, we're just going to end up at the nerd equivalent of pistols at dawn. You're telling people to use SSL with this. That is good. With SSL in the mix, my only real issue with AUTHO.ME is that it's a lot of moving parts for (what I think is) minimal value. You think "not having to implement bcrypt or PBKDF2" is major value. Guess what: this point is not worth a huge argument. And it's absolutely not worth a line-by-line evaluation of your crypto code, so I'm just not going to do it. If you're planning on a doing an indie two-factor auth project, that value may be less minimal. I have no coherent opinion that stuff. Good luck with it. If you do something crazy, I'll call you on it, which is I think what you want. Ignore Kaminsky, by the way. I can't imagine how using RSA instead of SRP could possibly make this safer, but I can imagine lots of ways in which it could make you much less safe.