[tptacek]

I'm sorry you've taken offense. I'm not writing well today.

Again, the core of your misunderstanding here is your belief that SHA256 is a security function. It isn't.

Also, you believe you're simply using SHA256. You're not. You're using SHA256(nonce, password), which is a construction, not an algorithm.

There's nothing wrong with constructions; every security protocol uses them. But you need to recognize the merits and problems with the construction you've ended up using. Your construction is terribly vulnerable to incremental brute force cracking. There are much better constructions that don't have this problem; scrypt and bcrypt are among them. There's also PBKDF2 and "stretched" SHA256.

But, and this will annoy you to hear: security-critical code isn't something you should "learn on the job". Take someone else's secure system (in Ruby, use ruby-bcrypt, which is excellent) and build on that instead.

[KevinMS]

Believe me, I understand what these one way hashing algorithms are, but you have to cut me a little slack for not knowing the exact proper terminology, since this is not my field. I know its not some magical "security function", actually I never used that term, but I did say "security hash", which I took to mean a hashing function used in security, like website authentication.

But its baffling that you are saying this is not something I should "learn on the job", since I'm doing exactly what the other alternative libraries are doing, except a few offer more configuration. Authlogic, Clearance and Devise all are doing what I'm doing, some a little better, by offering bcrypt, some much worse, by defaulting to SHA1. I hope that, although it looks like you are singling out my humble plugin for criticism, you are actually criticizing most existing plugins. If you want to do that, its your call, but I'm just offering an alternative.

In fact I was going to use bcrypt, but I discovered that it require some installation to use, and I didn't want to make a simple plugin more complicated. Why did I think this was ok? Because, as I mentioned before, I did a little digging and found almost nothing warning about using sha2 for hashing passwords, so I assumed it was still considered good enough.

I really sounds like you are criticizing auto_hash as some poorly attempted one way hashing function but its only a plugin with a single line, that does anything crypto.

  Digest::SHA2.new.update(value + salt)

If I had found a single reference to sha2 not being secure enough for website passwords I would have simply replaced it with this line

  BCrypt::Password.create(value + salt)

I would hardly call that that failing of somebody who shouldn't be "learning on the job".

AMENDMENT: Not a simple 1 line drop in, but I'm getting there :)

Thanks to everybody voting me down for no reason I can see.

[tptacek]

Ok, I didn't vote you down, but let me help you out:

The fact that the mistake you made is only one line of code has nothing to do with anything. A single-line coding error (blindly offsetting malloc's return) broke all of Flash. Every line counts.

If that sucks and feels unfair, I agree with you. You can mitigate this problem by not writing security code.

[statictype]

I'm reading this thread from top to bottom and it looks like both sides are talking past each other.

His point: His plugin is a wrapper that provides a basic framework for handling authentication. He's not implementing his own cryptography. He happens to use an SHA256 construction as part of it because that's what he's seen as one of the standard ways of handling passwords.

Your point: Don't use salted SHA256 for passwords. Use bcrypt.

I think this whole conversation could have been snipped off if you had started with "change auto_hash to use bcrypt instead of SHA256 since it's more secure".

[tptacek]

It'd be great if he fixed auto_hash to use bcrypt instead of SHA256; this is, after all, the entirety of my original comment about his code.

Just be aware that once he replaces auto_hash with bcrypt, auto_hash has literally no functionality anymore; bcrypt-ruby already does all of what auto_hash does, better.

[KevinMS]

I'm on it right now, would have been done last night but having trouble with rails 3.0 and gem paths.

But its not true it wont have any functionality, it does what it claims to do, which isn't much, but its something.

Putting

  auto_hash :password, :field2, :field3

In a model will automate the process of "cryptofying" (using a fake word to avoid any more terminology disputes) database fields :password, :field2, :field3 upon save or update

Then it will give you a dynamic accessors like user.password_match?, user.field2_match?

This saves lines of ugly code I don't want to look it, and also frees up the models before_save hook.

Amendment: I think this will make auto_hash the only auth related plugin that defaults to, and only offers, bcrypt

[tptacek]

Yeah, bcrypt-ruby already does that, doesn't it?

[KevinMS]

Thats up to you to decide, here a comparison:

Here is bcrypt-ruby

  class User < ActiveRecord::Base

    include BCrypt

    def password
      @password ||= Password.new(password_hash)
    end

    def password=(new_password)
      @password = Password.create(new_password)
      self.password_hash = @password
    end

  end

Here is auto_hash

  class User < ActiveRecord::Base
    auto_hash :password
  end

[tptacek]

Not sure I'd want to introduce a plugin dep to get rid of 7 lines of code (you don't need the "include"), but, OK.