3 ms·

Actually, no that's not the point of autho.me. I know you keep thinking it's about me making a secure authentication that competes with bcrypt+ssl. It's actua

by zedshaw 16y ago

Actually, no that's not the point of autho.me. I know you keep thinking it's about me making a secure authentication that competes with bcrypt+ssl. It's actually for the purposes I laid out in the blog post: 1. An easy to setup secure auth system that's at least as secure as the others available. Not more secure, but just as secure. For example, your attack of protecting against content modification applies to all login systems. Every last one. Phishing also applies to all of them. I'm trying to tease out what ones are particular to autho.me and cover those. 2. The ability to manage users across multiple domains and organizations. 3. The ability to share or trade accounts with other trusted partners. This one is dubious because I don't know how users will like it. Really gotta figure out the usability of this. 4. An easy way to do 2-factor authentication with phones. So, don't be blinded by the SRP. That's just there to make the other features work. I'd also say if you're going put up specific attacks, then you should give ones that aren't also attacks against the things you promote. If you evaluate autho.me from the point of view of an infinitely capable super hacker who can always modify content, then all logins are vulnerable. I'd also like demonstrations of actual javascript turing completeness or mathematic failures that aren't handled by Tom Wu's SJCL. If there's flaws in Javascript's math such that it causes failures, then I'd like some concrete examples that don't require "infinit super hacker injects code" attacks. In otherwords, I'd like demonstrations of the SRP data that's publicly sent and an attack against it because of a failure in javascript mathematics, sjcl, or my code. Anyway Thomas, I don't take it personally, even if you are a bit sensationalist about it.

tptacek 16y ago
Why not read Nate Lawson's blog post? This will be the second time I've recommended it to you. One of the reasons I'm not going into too much depth is, why would I recap all of Nate Lawson? You're doing crypto dev, you should be reading him already. Your invocation of SJCL is also a bit of a straw-man. SJCL doesn't do straight-up number-theoretic crypto; even the AE cipher modes it offers avoids it. You're doing SRP in Javascript. You also keep calling it "Tom Wu's SJCL". You're saying that because "Tom Wu" is the name on SRP. Tom Wu didn't write SJCL. The SJCL authors, for what it's worth, claim "the best security which is practically available in Javascript", follow by a parenthesis, followed by the word "Unfortunately", followed by more words you should read. The two factor stuff, by the way? News to me as of this post. Twilio and 2-factor auth is a good idea (note though that I'm biased, as my friend Dug is doing something very similar --- http://www.duosecurity.com http://www.duosecurity.com).
- zedshaw 16y ago
  I did read his post, but there isn't a single actual demonstration of his claims that javascript math is flawed: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... All of his exploits talk about attacks that are just browser attacks, but nothing that says what you're saying about an actual exploit in the math of javascript. His attacks also assume an infinitely capable attacker who can always alter content, which is pointless because all browser based security, even your own proposed bcrypt, is vulnerable to all of his attacks. Also, my invocation of SJCL is not straw man, it's the actual library I'm using, so if you're going to do an exploit that takes advantage of a flaw in javascript math, then that's what you'd use. It's a concrete thing to focus on as an attack vector. That's sort of the inverse of "straw man". Finally, if you are saying that this is the first time you're hearing about the Twilio 2-factor auth then you didn't even read the blog post.
  - tptacek 16y ago
    No, Zed, I'm saying the post we're commenting on is the first time I've heard about you doing 2-factor auth. Why would you think I would comment on a post I hadn't read? You keep talking about "the math of the Javascript". You're a smart guy. I think you know that we're not saying the math in SJCL is wrong. I don't know what "just browser attacks" mean; you're asking the browser to implement cryptography, the browser is relevant. Nate does talk about "the math of Javascript", by the way.
    - zedshaw 16y ago
      I know he talks about it, but he doesn't really. He starts talking about it, and then switches to a browser environment attack. The main crux of my disagreement with you is that you say: Doing javascript in the browser makes it more vulnerable to an exploit than just doing bcrypt+ssl passwords. However, if someone can exploit the browser (XSS, content modification, etc) then no login system is safe. In other words, you're pimping bcrypt+ssl as a better alternative because it's NOT vulnerable to browser environment exploits, but it is. Every browser is. A browser environment exploit is all the things you keep bringing up: cache poisoning, SSL exploits, phishing, XSS attacks, content modification, etc.

by zedshaw 16y ago

tptacek 16y ago

Why not read Nate Lawson's blog post? This will be the second time I've recommended it to you. One of the reasons I'm not going into too much depth is, why would I recap all of Nate Lawson? You're doing crypto dev, you should be reading him already. Your invocation of SJCL is also a bit of a straw-man. SJCL doesn't do straight-up number-theoretic crypto; even the AE cipher modes it offers avoids it. You're doing SRP in Javascript. You also keep calling it "Tom Wu's SJCL". You're saying that because "Tom Wu" is the name on SRP. Tom Wu didn't write SJCL. The SJCL authors, for what it's worth, claim "the best security which is practically available in Javascript", follow by a parenthesis, followed by the word "Unfortunately", followed by more words you should read. The two factor stuff, by the way? News to me as of this post. Twilio and 2-factor auth is a good idea (note though that I'm biased, as my friend Dug is doing something very similar --- http://www.duosecurity.com http://www.duosecurity.com).

zedshaw 16y ago
I did read his post, but there isn't a single actual demonstration of his claims that javascript math is flawed: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... All of his exploits talk about attacks that are just browser attacks, but nothing that says what you're saying about an actual exploit in the math of javascript. His attacks also assume an infinitely capable attacker who can always alter content, which is pointless because all browser based security, even your own proposed bcrypt, is vulnerable to all of his attacks. Also, my invocation of SJCL is not straw man, it's the actual library I'm using, so if you're going to do an exploit that takes advantage of a flaw in javascript math, then that's what you'd use. It's a concrete thing to focus on as an attack vector. That's sort of the inverse of "straw man". Finally, if you are saying that this is the first time you're hearing about the Twilio 2-factor auth then you didn't even read the blog post.
- tptacek 16y ago
  No, Zed, I'm saying the post we're commenting on is the first time I've heard about you doing 2-factor auth. Why would you think I would comment on a post I hadn't read? You keep talking about "the math of the Javascript". You're a smart guy. I think you know that we're not saying the math in SJCL is wrong. I don't know what "just browser attacks" mean; you're asking the browser to implement cryptography, the browser is relevant. Nate does talk about "the math of Javascript", by the way.
  - zedshaw 16y ago
    I know he talks about it, but he doesn't really. He starts talking about it, and then switches to a browser environment attack. The main crux of my disagreement with you is that you say: Doing javascript in the browser makes it more vulnerable to an exploit than just doing bcrypt+ssl passwords. However, if someone can exploit the browser (XSS, content modification, etc) then no login system is safe. In other words, you're pimping bcrypt+ssl as a better alternative because it's NOT vulnerable to browser environment exploits, but it is. Every browser is. A browser environment exploit is all the things you keep bringing up: cache poisoning, SSL exploits, phishing, XSS attacks, content modification, etc.