> I genuinely don't know the answers to any of these questions, so I'd really love to know.
Well, I don't speak for the project as a whole, so I'm going to just answer personally. I'll try to channel the rest of the core team as best I can, but please don't take any of the below as any sort of "official" thing. I may very well have a different point of view or be in the minority -- I often am, actually.
> Does Django (the project as a whole) want to provide the best possible security, within reason, for its contrib.auth module?
I certainly do, and I'm sure the rest of the team feels similarly. We take security issues very seriously and I'm disappointed we've not been able to demonstrate that through our past actions (i.e. built-in XSS and CSRF protection, our security releases, etc.) This indicates to me that we haven't done a good job being clear about our goals with regard to security. So that's something to work on.
I think, though, that reasonable people can -- and do -- disagree about what "within reason" means. I mean, are we building Django to protect against script kiddies? Malicious employees? Corporate espionage? Government agencies?
Me, I suspect I'd choose to fold in the face of a lawsuit or subpoena, so I don't particularly care if my passwords are safe against the NSA or something. But that's because I'm a spoiled comfortable middle class yutz.
> Is bcrypt not the best possible security, or reasonably close to it?
Personally I have no idea. I'm not a security expert, nor am I even a well-informed amateur. I've read (here and on Reddit, mostly) that bcrypt is the best there is. I've read that bcrypt is for lamers and scrypt is better. I've also been told that salts & sha1 is fine. I've also been told that sha1 will eat my children and burn my house down. I'm honestly not qualified to judge.
Given what I know, my feeling is that bcrypt/scrypt is certainly an improvement over sha1, and probably an improvement over any sha version. I'm not convinced that it's an improvement over, say, multiple rounds of a sha algorithm.
More importantly, I'm not clear on exactly how big a deal this is. There's a spectrum: at one end, we activate our security policy, halt everything, and release new versions, damned the backwards compatibility concerns. At the other end of the spectrum we do nothing. I really don't know where on this spectrum the issue falls. I suspect that it's somewhere a bit more serious than the potential timing attacks we just fixed in trunk, but maybe a bit less serious than the DOS attack our last security release fixed.
> Is providing bcrypt hashing for passwords in contrib.auth not within the realm of reasonable effort? This could mean rewriting bcrypt in pure Python and including it in contrib, to support Windows users.
Of course it's possible, but the devil as they say is in the details. I think it should be possible to support bcrypt if it's installed, but the concerns about data portability need to be addressed in some way. At the very least there should be some "I don't care about data portability" flag you can set to turn on bcrupt support.
A pure-Python bcrypt implementation would certainly help. But I certainly am not going to rewrite bcrypt -- I know enough about crypto to know that I shouldn't be allowed with a thousand miles of writing an algorithm by hand. And frankly there aren't any active committers I'd trust to write such an implementation. It would have to come from a pretty unimpeachable source, wouldn't you agree?
> If bcrypt hashing is secure and reasonable to implement, and Django wants to provide the best security possible (within reason), why is this not a blocking issue for Django 1.3?
Because nobody proposed it and we're well past feature freeze for 1.3 and very close to cutting a release candidate. Also because there's a great third-party app that provides this feature in a very easy-to-use way :)
But If a majority of the community wanted to make bcrypt (or whatever) a blocking feature for 1.3 then I'd go along with it. I'd argue against it, but again I'm just one voice. A loud one, maybe, but I'd like to think I can take being wrong graciously. I was against template auto-escaping originally, for example, so clearly I'e already got a good track record of being wrong about security.
I hope that helps; it's late and I've had a long day. Please ask if I'm not being clear.
I think, though, that reasonable people can -- and do -- disagree about what "within reason" means.
Absolutely, which is where my next questions come from.
I'm not convinced that it's an improvement over, say, multiple rounds of a sha algorithm.
Sure, for this conversation feel free to replace "bcrypt" with "configurable rounds of SHA1".
More importantly, I'm not clear on exactly how big a deal this is.
I agree here.
Yes, bcrypt is better.
Is it "better enough" to warrant backwards-incompatible changes? Maybe not.
I'm not clear on Django's database-compatibility policy though. Are databases created with Django 1.X guaranteed to work with Django 1.Y (where Y < X)? If not, then there are no problems. If so, then you're right, a backwards incompatible change like this is not trivial.
Maybe I completely missed this in the docs.
At the very least there should be some "I don't care about data portability" flag you can set to turn on bcrupt support.
This goes back to my question about databases working with older versions of Django. Did I miss an important part of the docs?
A pure-Python bcrypt implementation would certainly help. But I certainly am not going to rewrite bcrypt -- I know enough about crypto to know that I shouldn't be allowed with a thousand miles of writing an algorithm by hand. And frankly there aren't any active committers I'd trust to write such an implementation. It would have to come from a pretty unimpeachable source, wouldn't you agree?
This is the first argument that really convinces me. If you need to support Windows and don't have anyone you trust to write a real crypt implementation in pure Python, that kind of kills the idea in its tracks.
A third-party app usable by non-Windows-users seems like the best option.
I hope that helps; it's late and I've had a long day. Please ask if I'm not being clear.
Comments
> I genuinely don't know the answers to any of these questions, so I'd really love to know.
Well, I don't speak for the project as a whole, so I'm going to just answer personally. I'll try to channel the rest of the core team as best I can, but please don't take any of the below as any sort of "official" thing. I may very well have a different point of view or be in the minority -- I often am, actually.
> Does Django (the project as a whole) want to provide the best possible security, within reason, for its contrib.auth module?
I certainly do, and I'm sure the rest of the team feels similarly. We take security issues very seriously and I'm disappointed we've not been able to demonstrate that through our past actions (i.e. built-in XSS and CSRF protection, our security releases, etc.) This indicates to me that we haven't done a good job being clear about our goals with regard to security. So that's something to work on.
I think, though, that reasonable people can -- and do -- disagree about what "within reason" means. I mean, are we building Django to protect against script kiddies? Malicious employees? Corporate espionage? Government agencies?
Me, I suspect I'd choose to fold in the face of a lawsuit or subpoena, so I don't particularly care if my passwords are safe against the NSA or something. But that's because I'm a spoiled comfortable middle class yutz.
> Is bcrypt not the best possible security, or reasonably close to it?
Personally I have no idea. I'm not a security expert, nor am I even a well-informed amateur. I've read (here and on Reddit, mostly) that bcrypt is the best there is. I've read that bcrypt is for lamers and scrypt is better. I've also been told that salts & sha1 is fine. I've also been told that sha1 will eat my children and burn my house down. I'm honestly not qualified to judge.
Given what I know, my feeling is that bcrypt/scrypt is certainly an improvement over sha1, and probably an improvement over any sha version. I'm not convinced that it's an improvement over, say, multiple rounds of a sha algorithm.
More importantly, I'm not clear on exactly how big a deal this is. There's a spectrum: at one end, we activate our security policy, halt everything, and release new versions, damned the backwards compatibility concerns. At the other end of the spectrum we do nothing. I really don't know where on this spectrum the issue falls. I suspect that it's somewhere a bit more serious than the potential timing attacks we just fixed in trunk, but maybe a bit less serious than the DOS attack our last security release fixed.
> Is providing bcrypt hashing for passwords in contrib.auth not within the realm of reasonable effort? This could mean rewriting bcrypt in pure Python and including it in contrib, to support Windows users.
Of course it's possible, but the devil as they say is in the details. I think it should be possible to support bcrypt if it's installed, but the concerns about data portability need to be addressed in some way. At the very least there should be some "I don't care about data portability" flag you can set to turn on bcrupt support.
A pure-Python bcrypt implementation would certainly help. But I certainly am not going to rewrite bcrypt -- I know enough about crypto to know that I shouldn't be allowed with a thousand miles of writing an algorithm by hand. And frankly there aren't any active committers I'd trust to write such an implementation. It would have to come from a pretty unimpeachable source, wouldn't you agree?
> If bcrypt hashing is secure and reasonable to implement, and Django wants to provide the best security possible (within reason), why is this not a blocking issue for Django 1.3?
Because nobody proposed it and we're well past feature freeze for 1.3 and very close to cutting a release candidate. Also because there's a great third-party app that provides this feature in a very easy-to-use way :)
But If a majority of the community wanted to make bcrypt (or whatever) a blocking feature for 1.3 then I'd go along with it. I'd argue against it, but again I'm just one voice. A loud one, maybe, but I'd like to think I can take being wrong graciously. I was against template auto-escaping originally, for example, so clearly I'e already got a good track record of being wrong about security.
I hope that helps; it's late and I've had a long day. Please ask if I'm not being clear.
Yes, bcrypt is better.
Is it "better enough" to warrant backwards-incompatible changes? Maybe not.
I'm not clear on Django's database-compatibility policy though. Are databases created with Django 1.X guaranteed to work with Django 1.Y (where Y < X)? If not, then there are no problems. If so, then you're right, a backwards incompatible change like this is not trivial.
Maybe I completely missed this in the docs.
This goes back to my question about databases working with older versions of Django. Did I miss an important part of the docs? This is the first argument that really convinces me. If you need to support Windows and don't have anyone you trust to write a real crypt implementation in pure Python, that kind of kills the idea in its tracks.A third-party app usable by non-Windows-users seems like the best option.
Definitely. Thanks for taking the time to answer.