Permalink
Browse files

Bumped to Sha512

  • Loading branch information...
1 parent f97f890 commit 20fcb6fafb033deefa320cb4877fcd93d67a1ac1 @binarylogic committed Oct 28, 2008
Showing with 9 additions and 6 deletions.
  1. +2 −1 CHANGELOG.rdoc
  2. +3 −1 README.rdoc
  3. +1 −1 lib/authgasm.rb
  4. +3 −3 lib/authgasm/{sha256_crypto_provider.rb → sha512_crypto_provider.rb}
View
@@ -1,6 +1,7 @@
-== 0.10.0 released 2008-10-24
+== 0.10.1 released 2008-10-24
* Sessions now store the "remember token" instead of the id. This is much safer and guarantees all "sessions" that are logged in are logged in with a valid password. This way stale sessions can't be persisted.
+* Bumped security to Sha512 from Sha256.
== 0.10.0 released 2008-10-24
View
@@ -169,7 +169,9 @@ The errors in Authgasm work JUST LIKE ActiveRecord. In fact, it uses the exact s
This is one of my favorite features that I think its pretty cool. It's things like this that make a library great and let you know you are on the right track.
-What if a user changes their password? You have to re-log them in with the new password, recreate the session, etc, pain in the ass. Or what if a user creates a new user account? You have to do the same thing. Here's an even better one: what if a user is in the admin area and changes his own password? There might even be another place passwords can change. It shouldn't matter, your code should be written in a way where you don't have to remember to do this.
+Just to clear up any confusion, Authgasm does not store the plain id in the session. It stores a token. This token changes with the password, this way stale sessions can not be persisted.
+
+That being said...What if a user changes their password? You have to re-log them in with the new password, recreate the session, etc, pain in the ass. Or what if a user creates a new user account? You have to do the same thing. Here's an even better one: what if a user is in the admin area and changes his own password? There might even be another place passwords can change. It shouldn't matter, your code should be written in a way where you don't have to remember to do this.
Instead of updating sessions all over the place, doesn't it make sense to do this at a lower level? Like the User model? You're saying "but Ben, models can't mess around with sessions and cookies". True...but Authgasm can, and you can access Authgasm just like a model. I know in most situations it's not good practice to do this but I view this in the same class as sweepers, and feel like it actually is good practice here. User sessions are directly tied to users, they should be connected on the model level.
View
@@ -3,7 +3,7 @@
require File.dirname(__FILE__) + "/authgasm/controller_adapters/rails_adapter" if defined?(Rails)
-require File.dirname(__FILE__) + "/authgasm/sha256_crypto_provider"
+require File.dirname(__FILE__) + "/authgasm/sha512_crypto_provider"
require File.dirname(__FILE__) + "/authgasm/acts_as_authentic"
require File.dirname(__FILE__) + "/authgasm/session/active_record_trickery"
require File.dirname(__FILE__) + "/authgasm/session/callbacks"
@@ -1,13 +1,13 @@
module Authgasm
- # = Sha256 Crypto Provider
+ # = Sha512 Crypto Provider
#
# The acts_as_authentic method allows you to pass a :crypto_provider option. This allows you to use any type of encryption you like. Just create a class with a class level encrypt and decrypt method.
# The password will be passed as the single parameter to each of these methods so you can do your magic.
#
# If you are encrypting via a hash just don't include a decrypt method, since hashes can't be decrypted. Authgasm will notice this adjust accordingly.
- class Sha256CryptoProvider
+ class Sha512CryptoProvider
def self.encrypt(pass)
- Digest::SHA256.hexdigest(pass)
+ Digest::SHA512.hexdigest(pass)
end
end
end

0 comments on commit 20fcb6f

Please sign in to comment.