I just started playing with Grails and working on simple registration/login feature.
I have this simple domain object:
class Person {
String firstName, lastName, email
String login, password
static constraints = {
firstName nullable: true
lastName nullable: true
}
static mapping = {
password type: GormEncryptedStringType
}
}
I am saving Person object just fine. But then when I try to retrieve it for login purposes using Criteria API, it won't find it:
def criteria = Person.createCriteria()
def person = criteria.get {
and {
eq("login", params.login)
eq("password", params.password)
}
}
If I remove eq("password", params.password) or change it to something not encrypted it works just fine. Anyone have an idea how to handle that?
You're doing it wrong (security). You don't encrypt passwords, you hash them. Hashing is one-way and lossy, whereas encryption is two-way and lossless, but if you can decrypt the passwords then you're vulnerable to attackers who gain access to the decryption keys, and then they'll be able to decrypt them too.
If you use hashing, then you can (but of course shouldn't) let anyone view the hashed passwords because they're useless if you use a good hashing scheme. Bcrypt is one of the best and is easy to use.
Instead of decrypting the stored encrypted password to verify a cleartext password from a user authentication attempt, you should hash the supplied password and validate it against the stored hashed password. For some algorithms this is a simple as checking that the values are the same, but that's not the case with Bcrypt since the algorithm always generates a different hash for each invocation. But the algorithm can validate two hashed passwords, so that's not a problem.
So the real fix to your problem is to stop using encryption, and stop 'rolling your own' security. spring-security-core is a popular option.
Related
We have a Grails Web App using Spring Security and a User object that has username, email and fullname. In lots of places we call springSecurityService.currentUser when processing requests - this currently works fine and returns the user based on the username (which previously was always an email address and therefore was unique)
However, a change is now required where the username may not be an email and is therefore not unique in a User object - it must also take into account the optional email and fullname fields. This means that we can have two users called 'bobsmith' as long as their email/fullname values are different.
From what I can tell the springSecurity.currentUser does a lookup on the User table based on just the username - this will no longer work for us as it will probably just retrieve the first matching username it finds which could be wrong.
Is it possible to configure Grails/Spring Security to set the current user based on multiple fields. I know exactly what I want to do which is effectively in pseudo-logic (I know this is not possible):
if (email && !fullname) {
springSecurityService.currentUser = User.findByUsernameAndEmail(username)
} else if (!email && fullname) {
springSecurityService.currentUser = User.findByUsernameAndFullname(username, fullname)
} else if (email && fullname) {
springSecurityService.currentUser = User.findByUsernameAndEmailAndFullname(username, email, fullname)
}
The SpringSecurityService getCurrentUser() is:
def getCurrentUser() {
if (!isLoggedIn()) {
return null
}
def User = getClassForName(securityConfig.userLookup.userDomainClassName)
if (principal instanceof GrailsUser) {
User.get principal.id
}
else {
User.createCriteria().get {
String usernamePropertyName = securityConfig.userLookup.usernamePropertyName
eq usernamePropertyName, principal[usernamePropertyName]
cache true
}
}
}
The last part is what is being executed in our case:
User.createCriteria().get {
String usernamePropertyName = securityConfig.userLookup.usernamePropertyName
eq usernamePropertyName, principal[usernamePropertyName]
cache true
}
Is there a way of changing this functionality somehow ? I thought about adding a custom filter into the chain but not sure if this will make any difference based on the retrieval logic that is fixed to the username property (which I don't want to change as it is correct of course).
Any help or recommendations are much appreciated
getCurrentUser is a generic helper method that you never have to use (and it is not used by the plugin itself) - it's just there for your convenience. If it doesn't work in your application, don't use it - just create your own utility method with your custom logic.
In cases where your authentication logic is more complex than using the username and password properties, you can register a custom UserDetailsService and use your logic there.
Note that the concept of the 'current user' and the logic used during authentication are typically closely related but not it all cases, so you can make either or both of these changes depending on your needs.
I have a Grails application that uses the Spring Security Core and Spring Security LDAP plugins. I am using the bind method of authentication with an LDAP server as my only authentication provider. Why must I still store a password column in my database? My application has absolutely no need to store a value for a password, but it will not work if I remove the password field from the generated User domain class. Do I really have to store a password column with the value of null in my User table? Surely there must be a different approach to this.
I don't think you must!
simply define the password field as transient in your UserAccount class:
class UserAccount {
String password
static transients = [ 'password' ]
}
Today I upgraded the spring security version of the application I'm working on from 3.1.3 to 3.1.4, and I noticed a deprecation warning on the org.springframework.security.authentication.encoding.ShaPasswordEncoder class.
So I switched to the new org.springframework.security.crypto.password.StandardPasswordEncoder implementation.
I had it working and I'm able to register a new user and login in my application, but, as I feared, I'm not able to login using passwords generated with the previous ShaPasswordEncoder and my custom salt.
Since I have a database with many users already registered, what should I do to switch implementation without invalidating the old encoded passwords?
Is it even possible?
See also: How to use new PasswordEncoder from Spring Security
If you want to switch to a more secure password encoding mechanism, then I would recommend you use BCrypt. I would use something like this to migrate your users:
// Implement the old PasswordEncoder interface
public class MigrateUsersPasswordEncoder implements PasswordEncoder {
#Autowired
ShaPasswordEncoder legacyEncoder;
#Autowired
JdbcTemplate template;
BCryptPasswordEncoder bcryptEncoder = new BCryptPasswordEncoder();
#Override
public String encodePassword(String rawPass, Object salt) {
return bcryptEncoder.encode(rawPass);
}
#Override
public boolean isPasswordValid(String encPass, String rawPass, Object salt) {
if (legacyEncoder.isPasswordValid(encPass, rawPass, salt)) {
template.update("update users set password = ? where password = ?", bcryptEncoder.encode(rawPass), encPass);
return true;
}
return bcryptEncoder.matches(rawPass, encPass);
}
}
You can check what proportion of users have been migrated by the format of the password field. BCrypt strings have a distinctive syntax beginning with a $ sign.
One of the other answers points out that this code could accidentally update multiple passwords at the same time. The question stated that a custom salt was being used, so the chance of collisions is negligible if the salt is randomly chosen, but this might not always be the case. If two passwords were updated, what would the problem be? It would then be possible to detect that accounts have the same password from the bcrypt hashes. That's the case anyway since it requires that the SHA hashes were the same for the update to occur. If you think it might be a problem (e.g. because of poor salt choice or even the use of unsalted hashes) it would be trivial to modify the SQL to detect this and perform multiple updates with separate BCrypt hash values.
I tried to add a comment to the accepted answer, but alas, I don't have enough cred yet. :(
I believe the accepted answer's code snippet is potentially dangerous where it updates the password in the database. If the ShaPasswordEncoder produces the same results when encrypting (which is why the assumption is being made that the old password can be found, and I verified this is definitely true at least with a null salt on the ShaPasswordEncoder), you still cannot guarantee that the password is unique amongst all users. You could, by chance, share the same password as another user on the system, and that SQL code would end up changing all users that happen to have your password.
I think the safest strategy is to not update the user's password, and instead provide a migration strategy that plans for the eventual removal of the ShaPasswordEncoder.
Use the provided example code.
Remove the code that updates the database.
Add a feature like, "Forgot your password" or "Generate a new password" to handle the eventual case of users not having created a new password when the ShaPasswordEncoder is removed. Like either when you upgrade to Spring Security that has it removed, or choose to remove it yourself.
Update your documentation or make it clear that in the next major release version of the software, that users will have had to re-save their passwords or will have to use the before-mentioned password reset feature.
Give the user the grace period of a major version release cycle to transition (they probably won't do it and just get caught in the reset password).
That's an excellent question and am looking forward to reading some answers.
AFAIK it's impossible to do in a single mass update: you just can't retrieve the original string from a hash. You would have to check during a login attempt if the submitted password matches either strategy and convert it to the new strategy if necessary, but that means you would have to live with both encoding strategies until all users have logged in and hence all passwords have been converted. Not very convenient nor necessarily intuitive for new developers coming on board.
I move to implement class PasswordEncoder
org.springframework.security.crypto.password.PasswordEncoder
This solution help me to fixed deprecated PasswordEncoder.
Code:
public class LegacySupportPasswordEncoder implements PasswordEncoder {
private final BCryptPasswordEncoder bcryptEncoder;
private final JdbcTemplate jdbcTemplate;
#Autowired
public LegacySupportPasswordEncoder(#Qualifier("passwordEncoder") final BCryptPasswordEncoder bcryptEncoder,
final RoutingDataSource dataSource) {
this.bcryptEncoder = bcryptEncoder;
this.jdbcTemplate = new JdbcTemplate(dataSource);
}
#Override
public String encode(CharSequence rawPassword) {
return this.bcryptEncoder.encode(rawPassword);
}
#Override
public boolean matches(CharSequence rawPassword, String encodedPassword) {
//Your code validate credential in database here
return this.bcryptEncoder.matches(rawPassword, encodedPassword);
}
}
I have a simple web app that has a login page, the front end domain has a simple model with:
string username {get;set;}
string password {get;set;}
However it is encrypted with sha256 before it is sent over to the data domain object, originally the data domain was:
string username {get;set;}
string password {get;set;}
So I would take the password from the ui, encrypt it then using the Encoding.GetString() method, get back a string for persisting. However when I try to persist the data it just seems to give an exception, which I believe to be down to the characters in the string not being valid.
After looking around some people have recommended storing it as a varbinary(32) and using a byte[] password {get;set;} within the data layer, however I couldn't get Nhibernate to map it correctly.
So can anyone tell me the best practise on storing hashed passwords with Nhibernate and SqlServer or MySql. (The app supports both dbs)
You shouldn't use Encoding.GetString() on a SHA value since it will produce text that may not store correctly, or worse, give an exception. Rather use something like Convert.ToBase64String.
For example, I created this domain class:
package loginproject
class User {
String name
String password
Boolean state
static constraints = {
}
}
I think it is a good idea to encrypt the password string but I do not know where to start. What algorithm? What do I need to do?
If you need a complete authentication and authorization solution +1 for spring security core plugin. If you just want to encrypt a domain class or parts of it in the DB, go for http://www.grails.org/plugin/crypto.
You can utilize a plugin, such as Spring Security core plugin. And actually, we often save password hash instead of its encryption.