I am trying to implement BCrypt password encryption using Spring Security. For some reason the password validation is failing for what should be a valid password. The password was created in the same app, and passes the authentication check when I hard code it in a unit test. But, for some reason when it is running on the server it fails. I have checked that it's using the same JRE, the same number of iterations (stored in the hash). I tried reducing it to the bare minimum of code to figure out what's wrong. I am stuck at the point where this statement:
BCrypt.checkpw("password123", "$2a$10$kyRMcxNqagw.ny369X4AsumV4cvHt4Usfvm.rGNDRnxP2SLKioFhu")
returns true when run in a unit test, but fails when run in my PasswordEncoder live on the server. Any ideas on why this is failing?
I figured out my mistake. At one point our code was converting passwords to uppercase. I removed it some places, but missed one. So comparing all caps password to mixed case password failed (as one would expect it should).
Related
I'm using kong in serverless mode and it seems that in this mode password has to show up as an hashcode.
In this topic they say how to generate one using lua but I have no idea on how to execute this thing on my machine.
Any idea or equivalent one?
Solved: they suggested a very complicated way.
The password is just a sha1 calculated by concatenating the password with a generated uuid.
I used online tools to generate my password
Depending on a particular device type, we will toggle between basic auth (default) to digest auth.
When implementing this decision, getting this error:
ArgumentError: only one authentication method, :basic_auth or :digest_auth may be used at a time
If forced to basic only - works fine. Including HTTParty in both client classes. And including it in the parent class for a particular request that is device specific.
Any insight would be appreciated.
I think the crux of this is that HTTParty is not thread-safe and thus those instances are shared across classes and thus why you cannot change lower-level configuration changes.
Honestly I ditched HTTParty because of this and moved to RestClient which is more full-featured.
So...after digging into their gem, it appears they build a basic auth right at the start when initializing the Request class - even with a digest auth hash present in the options.
There is no consideration to checking the options, just parse the url for the credentials and immediately build a basic auth in the options for the Request. This gets you to the error above.
Putting a condition to check for pre-existing auths in my local project for the initialize method solved my problem.
This question is for a production Grails app using Spring Security configured with BCrypt.
To keep up with increasing server CPU speed, I would like to up the value of the grails.plugin.springsecurity.password.bcrypt.logrounds property so that password hashing takes longer and is less susceptible to attack.
At first thought, I figured this was a daunting task requiring a trickle approach as users logged in or massive re-encoding and custom login handlers, but it appears to work without any other change when trying it locally between runs (with a persistent database, simulating a non-local deploy).
I'm guessing this is because the logrounds is stored on the password hash: when going from 10 to 20 between runs locally, for example, the passwords look as follows
$2a$10$i/PEPcvSj... <-- account created when logrounds was set to 10
'$2a$20$3GGujw6o... <-- account created when logrounds was set to 20
I have tested:
Old accounts created before the change can still log in.
Old accounts can change their password, and the new hashes use the new logrounds setting
New accounts can be created and logged in as expected
Trying to log in with an account that does not exist takes the expected new delay.
Is there any reason not to proceed with the change? The high degree of caution here is because a mistake that prevents production login in any way would be extremely costly
Everything worked as expected, so the answer is that yes, you can. You can change the logrounds without impact to existing accounts as the logrounds used to produce the hash is built into the hash. Nice feature of BCrypt
I'm trying to migrate old Grails app from AppFog to Linode servers. I migrated code and MYSQL database, but I couldn't log in with old credentials.
For some reason, I suspected that I forgot password so I simply deleted my user directly from the database and let Bootstrap.groovy creates a new one with known password so I managed to log in again.
Next day, when I tried to log in again, I received wrong credentials message so I looked at the database and verified that hashed password is still the same. I repeat delete user and Bootstrap procedure and noticed that password hash is different than the previous one for the same password.
Again, I managed to log in through GUI and even (via GUI) update password for other users (user from Bootstrap.groovy have admin role). I verified that all password hashes were updated in databases and I verified each account login via GUI, everything was fine.
This morning, when I tried to log into the application I was rejected again on several accounts that I verified last night.
The only thing that I noticed that is different is the format of hashed password: previously it was a sequence of chars and numbers but now it always starts with $2a$ and containing special characters.
I noticed few forums and SO post mentioning that using spring-security-gui could cause double hashing of passwords but I'm not using that plugin.
Here is the list of (relevant) plugins that I'm using:
tomcat:7.0.52.1
hibernate:3.6.10.9
database-migration:1.3.8"
spring-security-core:2.0-RC4"
I just noticed that the old version of app was using spring-security-core:1.2.7.3 and latest one is using 2.0-RC4 (I updated some out-dated plugins before migration)
UPDATE:
Unfortunatelly, problem is still active. I bootstraped user and verify that password is hashed in 'sha format'. I can log in with that user and change passwords of other users. I verified that all passwords are sha hashed in database. I can log with each user that I resetted password including bootstraped one. After one day (aproximately) I can not log again with previously used credentails on any user. I checked database and password hashes are same as before. Nothing in tomcat, mysql or syslog logs. Same application was running on AppFog for more that one year without restart and no problems were noticed. I'm not 100% sure what spring security plugin version was used at AppFog site (legacy maintenance) but, only thing that is changed is version of that plugin (if it wasnt used before). There are no background jobs that can trigger this behavior (e.g. user.save() calls) so I don't have a clue what could go wrong or what else I need to set.
Set the following two properties in your Config.groovy
grails.plugin.springsecurity.password.algorithm = "SHA-256"
grails.plugin.springsecurity.password.hash.iterations = 1
That will also allow you to log in with the old password. Spring Security 1.x uses the SHA-256 but the new Spring Security 2.x uses now bcrypt algorithms.
http://grails-plugins.github.io/grails-spring-security-core/v2/guide/newInV2.html
I have been having some trouble logging in when typing the credentials in the login page. For some reason, I am typing a wrong password even though I have checked the correct one in the database. So I thought of printing in the console the password that I type. How can I do that?
I wrote up an approach at http://burtbeckwith.com/blog/?p=2029 - this is a followup to this earlier post: http://burtbeckwith.com/blog/?p=2003
As I mention in the post, since this will print cleartext passwords on the console, be sure to remove this as soon as you determine and fix what's misconfigured.