Grails › Grails - user

Salting password

Classic

List

Threaded

19 messages Options

suryazi

Salting password

Hi,

I am using the Shiro plugin (Shiro 1.1.4) in my Grails application. I am using the below code to save the user in my bootstrap

def user = new User(username: "User", passwordHash: new Sha512Hash("password").toHex())
user.save()

I am able to login into the system using the above credentials.

My problem is after salting the password as below

def user = new User(username: "User", passwordHash: new Sha512Hash("password","User",1024).toHex())
user.save()

I am unable to logon and the system is showing invalid username/password message. Please let me know how to overcome it.

Joshua Kehn-2

Re: Salting password

You need to save the salt in the database.

Regards,

-Josh
___________________________
http://joshuakehn.com
Currently mobile

On Jul 23, 2012, at 8:29 AM, suryazi <[hidden email]> wrote:

> Hi,
>
> I am using the Shiro plugin (Shiro 1.1.4) in my Grails application. I am
> using the below code to save the user in my bootstrap
>
> def user = new User(username: "User", passwordHash: new
> Sha512Hash("password").toHex())
> user.save()
>
> I am able to login into the system using the above credentials.
>
> My problem is after salting the password as below
>
> def user = new User(username: "User", passwordHash: *new
> Sha512Hash("password","User",1024)*.toHex())
> user.save()
>
> I am unable to logon and the system is showing invalid username/password
> message. Please let me know how to overcome it.
>
>
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Salting-password-tp4632042.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Scott6666

Re: Salting password

I never quite understood the advantage of salting in the same database next the password hash itself. It seems that when the hackers crack into the database they take the salt with the hash so the protection added is minimal.

I suppose it protects when a hacker grabs it "over the wire" or maybe if the password is logged in a server log or something but the major thefts of info seem to be hacks directly into the database.

Anyone can help me here?

On Jul 23, 2012, at 8:34 AM, Joshua Kehn wrote:

> You need to save the salt in the database.
>
> Regards,
>
> -Josh
> ___________________________
> http://joshuakehn.com
> Currently mobile
>
> On Jul 23, 2012, at 8:29 AM, suryazi <[hidden email]> wrote:
>
>> Hi,
>>
>> I am using the Shiro plugin (Shiro 1.1.4) in my Grails application. I am
>> using the below code to save the user in my bootstrap
>>
>> def user = new User(username: "User", passwordHash: new
>> Sha512Hash("password").toHex())
>> user.save()
>>
>> I am able to login into the system using the above credentials.
>>
>> My problem is after salting the password as below
>>
>> def user = new User(username: "User", passwordHash: *new
>> Sha512Hash("password","User",1024)*.toHex())
>> user.save()
>>
>> I am unable to logon and the system is showing invalid username/password
>> message. Please let me know how to overcome it.
>>
>>
>>
>> --
>> View this message in context: http://grails.1312388.n4.nabble.com/Salting-password-tp4632042.html
>> Sent from the Grails - user mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

roos

Re: Salting password

In reply to this post by suryazi

Have you thought about using bcrypt instead of sha512? It might ease salt handling and is designed explicitly for password hashing.

Am 23.07.2012 um 14:29 schrieb suryazi:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Ian Roberts

Re: Salting password

In reply to this post by Scott6666

On 23/07/2012 13:38, Scott Eisenberg wrote:

> I never quite understood the advantage of salting in the same
> database next the password hash itself. It seems that when the
> hackers crack into the database they take the salt with the hash so
> the protection added is minimal.
>
> I suppose it protects when a hacker grabs it "over the wire" or maybe
> if the password is logged in a server log or something but the major
> thefts of info seem to be hacks directly into the database.
>
> Anyone can help me here?

The point of salting is to prevent the use of pre-computed rainbow
tables to crack passwords. If each user's password is salted with a
different random salt then you have to brute force each password
individually, and when you crack one password it doesn't automatically
let you in to any other account that has the same hash.

Ian

--
Ian Roberts | Department of Computer Science
[hidden email] | University of Sheffield, UK

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Andrew Todd

Re: Salting password

In reply to this post by Scott6666

On Mon, Jul 23, 2012 at 8:38 AM, Scott Eisenberg <[hidden email]> wrote:
> I never quite understood the advantage of salting in the same database next the password hash itself. It seems that when the hackers crack into the database they take the salt with the hash so the protection added is minimal.

You salt a password before hashing in order to prevent rainbow-table
attacks: https://en.wikipedia.org/wiki/Rainbow_table

The idea is to add enough data to make it computationally infeasible
to pre-calculate the hash value of every possible password-salt
combination.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

suryazi

Re: Salting password

This post was updated on .

In reply to this post by Joshua Kehn-2

I guess only salted password is saved in the database not the salt itself.

Joshua Kehn-2 wrote

You need to save the salt in the database.

Regards,

-Josh
___________________________
http://joshuakehn.com
Currently mobile

On Jul 23, 2012, at 8:29 AM, suryazi <[hidden email]> wrote:

> Hi,
>
> I am using the Shiro plugin (Shiro 1.1.4) in my Grails application. I am
> using the below code to save the user in my bootstrap
>
> def user = new User(username: "User", passwordHash: new
> Sha512Hash("password").toHex())
> user.save()
>
> I am able to login into the system using the above credentials.
>
> My problem is after salting the password as below
>
> def user = new User(username: "User", passwordHash: *new
> Sha512Hash("password","User",1024)*.toHex())
> user.save()
>
> I am unable to logon and the system is showing invalid username/password
> message. Please let me know how to overcome it.
>
>
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Salting-password-tp4632042.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

suryazi

Re: Salting password

This post was updated on .

In reply to this post by roos

I thought of using bcrypt, but to me the problem appears to be during the authentication process.

roos wrote

Have you thought about using bcrypt instead of sha512? It might ease salt handling and is designed explicitly for password hashing.

Am 23.07.2012 um 14:29 schrieb suryazi:

> Hi,
>
> I am using the Shiro plugin (Shiro 1.1.4) in my Grails application. I am
> using the below code to save the user in my bootstrap
>
> def user = new User(username: "User", passwordHash: new
> Sha512Hash("password").toHex())
> user.save()
>
> I am able to login into the system using the above credentials.
>
> My problem is after salting the password as below
>
> def user = new User(username: "User", passwordHash: *new
> Sha512Hash("password","User",1024)*.toHex())
> user.save()
>
> I am unable to logon and the system is showing invalid username/password
> message. Please let me know how to overcome it.
>
>
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Salting-password-tp4632042.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

ideasculptor

Re: Salting password

On Mon, Jul 23, 2012 at 6:18 AM, suryazi <[hidden email]> wrote:

I though of using bcrypt, but to me the problem appears to be during the
authentication process.

The authentication process must use the same salt when encrypting the password prior to looking up the user. Most security frameworks do something equivalent to this:

String username = params.username

String password = params.password

// has password with whatever salt is appropriate

String passwdHash = hashPassword(username, password)

// load user that matches both username and hashed password

User user = loadUser(username, passwdHash) // select u.* where username = ? and password = ?

if (!user) throw new AuthenticationException("username and password didn't match")

Most frameworks will provide one or more mechanisms for specifying how the password gets hashed - some let you specify a property name of the user object, some let you provide a class or method which will be called to hash the password, etc. If you only changed the code where you store the hashed password, but didn't tell the framework how to generate the salted hash, then the two password hashes will never match except in the case where the salt causes no difference in the hash output (which should be nonexistent or incredibly rare).

suryazi

Re: Salting password

I fully agree with the below statement and procedures stated by Mr. Samuel. I did follow the same steps but it seems something weird is going underhood of the plugin or the Shiro framework itself. The basic authorization is done in AuthController with the below statement

def authToken = new UsernamePasswordToken(params.username, params.password as string)
............
.............
SecurityUtils.subject.login(authToken)

If I tried to use the salt password instead of the text password

def authToken = new UsernamePasswordToken(params.username, new Sha512Hash(params.password, "User").toHex() as string)

It is showing the Invalid username/password message. I appreciate if Mr. Peter Ledbrook, author of the plugin, or Mr. Les Hazlewood, chair of the shiro framework, shed some light on the authentication process and guide me to do the salting of the password during authentication process.

This seems to be the last hurdle in completion of my project and I am trying very hard to overcome it sooner. Appreciate the support of the forum members and hope to find the solution soon.

Samuel Gendler wrote

On Mon, Jul 23, 2012 at 6:18 AM, suryazi <[hidden email]> wrote:

> I though of using bcrypt, but to me the problem appears to be during the
> authentication process.
>
>
The authentication process must use the same salt when encrypting the
password prior to looking up the user. Most security frameworks do
something equivalent to this:

String username = params.username
String password = params.password
// has password with whatever salt is appropriate
String passwdHash = hashPassword(username, password)
// load user that matches both username and hashed password
User user = loadUser(username, passwdHash) // select u.* where username = ?
and password = ?
if (!user) throw new AuthenticationException("username and password didn't
match")

Most frameworks will provide one or more mechanisms for specifying how the
password gets hashed - some let you specify a property name of the user
object, some let you provide a class or method which will be called to hash
the password, etc. If you only changed the code where you store the hashed
password, but didn't tell the framework how to generate the salted hash,
then the two password hashes will never match except in the case where the
salt causes no difference in the hash output (which should be nonexistent
or incredibly rare).

sdthomas

Re: Salting password

This post has NOT been accepted by the mailing list yet.

If you are going to salt your passwords (and you should) you need modify your realm implementation to work with the salt. This is how I've done it in my application, using the plugin documentation:

1) Overide the credentialMatcher:

beans = {

credentialMatcher(org.apache.shiro.authc.credential.Sha512CredentialsMatcher){
storedCredentialsHexEncoded = false
hashSalted = true
hashIterations = 1024
}
}

2) Use the different credentialMatcher in the authenticate() closure in ShiroDbRealm:

...
byte[] salt = Base64.decodeBase64(user.passwordSalt.getBytes())

def account = new SimpleAccount(username,
user.passwordHash,
new org.apache.shiro.util.SimpleByteSource(salt),
"ShiroDbRealm")

3) I created a securityService to handle all authentication operations. It includes a method for hashing and salting:

public saltAndHashUser(password, user) {
RandomNumberGenerator rng = new SecureRandomNumberGenerator()
Object salt = rng.nextBytes()
user.passwordHash = new Sha512Hash(password, salt, 1024).toBase64()
user.passwordSalt = salt
return user
}

4) The service method can be used in the BootStrap class:

def user = new User(username:'foo')
securityService.saltAndHashUser('bar', user)
user.save(flush:true)

Hope this helps.

suryazi

Re: Salting password

Dear Thomas,

Thank you for the below code. One last question which classes should I need to import for RandomNumberGenerator and SecureRandomNumberGenerator() to work.

sdthomas wrote

If you are going to salt your passwords (and you should) you need modify your realm implementation to work with the salt. This is how I've done it in my application, using the plugin documentation:

1) Overide the credentialMatcher:

beans = {

credentialMatcher(org.apache.shiro.authc.credential.Sha512CredentialsMatcher){
storedCredentialsHexEncoded = false
hashSalted = true
hashIterations = 1024
}
}

2) Use the different credentialMatcher in the authenticate() closure in ShiroDbRealm:

...
byte[] salt = Base64.decodeBase64(user.passwordSalt.getBytes())

def account = new SimpleAccount(username,
user.passwordHash,
new org.apache.shiro.util.SimpleByteSource(salt),
"ShiroDbRealm")

3) I created a securityService to handle all authentication operations. It includes a method for hashing and salting:

public saltAndHashUser(password, user) {
RandomNumberGenerator rng = new SecureRandomNumberGenerator()
Object salt = rng.nextBytes()
user.passwordHash = new Sha512Hash(password, salt, 1024).toBase64()
user.passwordSalt = salt
return user
}

4) The service method can be used in the BootStrap class:

def user = new User(username:'foo')
securityService.saltAndHashUser('bar', user)
user.save(flush:true)

Hope this helps.

sdthomas

Re: Salting password

This post has NOT been accepted by the mailing list yet.

import org.apache.shiro.crypto.RandomNumberGenerator
import org.apache.shiro.crypto.SecureRandomNumberGenerator
import org.apache.shiro.crypto.hash.Sha512Hash

suryazi

RE: Salting password

Thank you

Sent from my HTC Touch Pro

From: sdthomas [via Grails] <ml-node+[hidden email]>
Sent: Wednesday, July 25, 2012 19:28
To: Samiullah S. Khan <[hidden email]>
Subject: Re: Salting password

import org.apache.shiro.crypto.RandomNumberGenerator
import org.apache.shiro.crypto.SecureRandomNumberGenerator
import org.apache.shiro.crypto.hash.Sha512Hash

If you reply to this email, your message will be added to the discussion below:

http://grails.1312388.n4.nabble.com/Salting-password-tp4632042p4632217.html

To unsubscribe from Salting password, click here.
NAML

This message contains confidential information and is intended only for the individual/Group named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Al Blagha Group or its subsidiaries . Finally, the recipient should check this email and any attachments for the presence of viruses. Al Blagha Group or its subsidiaries accepts no liability for any damage caused by any virus transmitted by this email.

Raphael Miranda

Re: Salting password

In reply to this post by Scott6666

If you don't store the salt in the database where then? In a more secure place? Why not storing the passwords there to begin with?

The best protection against rainbow table attacks is using a 'slow-enough' hash procedure so generating a rainbow table once your salt is stolen takes a very long time. So it takes 6 seconds to log in your user instead of 0.1ms, it also takes 2.5 years to crack all passes in a db instead of 23min.

The difference here is using Sha512 you'd have to do something like (1..1000).inject('pass'){ pass, num -> sha512(pass) }

while bcrypt pw hash is designed to be slow and gives you a cleaner interface BCrypt.hashpw('pass', 'salt')

Picking a slow hash algorithm probably gives the most bang for your buck.

On Mon, Jul 23, 2012 at 9:38 AM, Scott Eisenberg <[hidden email]> wrote:

I never quite understood the advantage of salting in the same database next the password hash itself. It seems that when the hackers crack into the database they take the salt with the hash so the protection added is minimal.

I suppose it protects when a hacker grabs it "over the wire" or maybe if the password is logged in a server log or something but the major thefts of info seem to be hacks directly into the database.

Anyone can help me here?

On Jul 23, 2012, at 8:34 AM, Joshua Kehn wrote:

> You need to save the salt in the database.
>
> Regards,
>
> -Josh
> ___________________________
> http://joshuakehn.com
> Currently mobile
>
> On Jul 23, 2012, at 8:29 AM, suryazi <[hidden email]> wrote:
>
>> Hi,
>>
>> I am using the Shiro plugin (Shiro 1.1.4) in my Grails application. I am
>> using the below code to save the user in my bootstrap
>>
>> def user = new User(username: "User", passwordHash: new
>> Sha512Hash("password").toHex())
>> user.save()
>>
>> I am able to login into the system using the above credentials.
>>
>> My problem is after salting the password as below
>>
>> def user = new User(username: "User", passwordHash: *new
>> Sha512Hash("password","User",1024)*.toHex())
>> user.save()
>>
>> I am unable to logon and the system is showing invalid username/password
>> message. Please let me know how to overcome it.
>>
>>
>>
>> --
>> View this message in context: http://grails.1312388.n4.nabble.com/Salting-password-tp4632042.html
>> Sent from the Grails - user mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

--
-Raphael Miranda

@raphaelom

suryazi

Re: Salting password

Well said. If the stored salt is the issue of concern then I would like to add new dimension to password hashing. Why not we wrote some code in the front end itself to alter the password, e.g., creating an image of the username and adding it to the given password along with the generated salt and hash the password with the combination of these three attributes. We just save the hash password and the salt into the DBRealm and will never disclose the image source code. When we need to authenticate we grab the username and process it to generate the image and add it to the given password along with salt from the DBRealm. Even if the hacker is having the salt and the password he cannot able to crack the password as the process of generating the image is embedded in the code itself and it will be hard to crack it. Further if we rehash the code multiple times using the above mentioned strategy then for sure it will give nightmares to the hackers or crytpoanalysis to find out the passwords. I would love to hear comments or suggestions to the suggested method.

My note on the slowness of the validation is to increase it exponentially. Initially validation should be fast and as the attempts continues system should get slow down in validating the credentials. A geniune user will successfully logon to the system within three attempts while a hacker script will attempt for 1000 times to get into the system. if we follow this strategy then we will be having happy users and annoyed hackers.

Raphael Miranda wrote

If you don't store the salt in the database where then? In a more secure
place? Why not storing the passwords there to begin with?

The best protection against rainbow table attacks is using a 'slow-enough'
hash procedure so generating a rainbow table once your salt is stolen takes
a very long time. So it takes 6 seconds to log in your user instead of
0.1ms, it also takes 2.5 years to crack all passes in a db instead of
23min.

The difference here is using Sha512 you'd have to do something like
*(1..1000).inject('pass'){
pass, num -> sha512(pass) } *
while bcrypt pw hash is designed to be slow and gives you a cleaner
interface *BCrypt.hashpw('pass', 'salt')*

Picking a slow hash algorithm probably gives the most bang for your buck.

On Mon, Jul 23, 2012 at 9:38 AM, Scott Eisenberg <[hidden email]>wrote:

> I never quite understood the advantage of salting in the same database
> next the password hash itself. It seems that when the hackers crack into
> the database they take the salt with the hash so the protection added is
> minimal.
>
> I suppose it protects when a hacker grabs it "over the wire" or maybe if
> the password is logged in a server log or something but the major thefts of
> info seem to be hacks directly into the database.
>
> Anyone can help me here?
>
> On Jul 23, 2012, at 8:34 AM, Joshua Kehn wrote:
>
> > You need to save the salt in the database.
> >
> > Regards,
> >
> > -Josh
> > ___________________________
> > http://joshuakehn.com
> > Currently mobile
> >
> > On Jul 23, 2012, at 8:29 AM, suryazi <[hidden email]> wrote:
> >
> >> Hi,
> >>
> >> I am using the Shiro plugin (Shiro 1.1.4) in my Grails application. I
> am
> >> using the below code to save the user in my bootstrap
> >>
> >> def user = new User(username: "User", passwordHash: new
> >> Sha512Hash("password").toHex())
> >> user.save()
> >>
> >> I am able to login into the system using the above credentials.
> >>
> >> My problem is after salting the password as below
> >>
> >> def user = new User(username: "User", passwordHash: *new
> >> Sha512Hash("password","User",1024)*.toHex())
> >> user.save()
> >>
> >> I am unable to logon and the system is showing invalid username/password
> >> message. Please let me know how to overcome it.
> >>
> >>
> >>
> >> --
> >> View this message in context:
> http://grails.1312388.n4.nabble.com/Salting-password-tp4632042.html
> >> Sent from the Grails - user mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list, please visit:
> >>
> >> http://xircles.codehaus.org/manage_email
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--
-Raphael Miranda
@raphaelom

roos

Re: Salting password

That is the same approach bcrypt uses. Slowness by intention with adaptive rounds.
Let's say you start with a 10 hashing rounds setup and after a while you figure out that might not be enough as computer get faster and faster, you can increase the no of rounds.

Am 26.07.2012 um 09:59 schrieb suryazi:

> Well said. If the stored salt is the issue of concern then I would like to
> add new dimension to password hashing. Why not we wrote some code in the
> front end itself to alter the password, e.g., creating an image of the
> username and adding it to the given password along with the generated salt
> and hash the password with the combination of these three attributes. We
> just save the hash password and the salt into the DBRealm and will never
> disclose the image source code. When we need to authenticate we grab the
> username and process it to generate the image and add it to the given
> password along with salt from the DBRealm. Even if the hacker is having the
> salt and the password he cannot able to crack the password as the process
> of generating the image is embedded in the code itself and it will be hard
> to crack it. Further if we rehash the code multiple times using the above
> mentioned strategy then for sure it will give nightmares to the hackers or
> crytpoanalysis to find out the passwords. I would love to hear comments or
> suggestions to the suggested method.
>
> My note on the slowness of the validation is to increase it exponentially.
> Initially validation should be fast and as the attempts continues system
> should get slow down in validating the credentials. A geniune user will
> successfully logon to the system within three attempts while a hacker script
> will attempt for 1000 times to get into the system. if we follow this
> strategy then we will be having happy users and annoyed hackers.
>
>
> Raphael Miranda wrote
>>
>> If you don't store the salt in the database where then? In a more secure
>> place? Why not storing the passwords there to begin with?
>>
>> The best protection against rainbow table attacks is using a 'slow-enough'
>> hash procedure so generating a rainbow table once your salt is stolen
>> takes
>> a very long time. So it takes 6 seconds to log in your user instead of
>> 0.1ms, it also takes 2.5 years to crack all passes in a db instead of
>> 23min.
>>
>> The difference here is using Sha512 you'd have to do something like
>> *(1..1000).inject('pass'){
>> pass, num -> sha512(pass) } *
>> while bcrypt pw hash is designed to be slow and gives you a cleaner
>> interface *BCrypt.hashpw('pass', 'salt')*
>>
>> Picking a slow hash algorithm probably gives the most bang for your buck.
>>
>> On Mon, Jul 23, 2012 at 9:38 AM, Scott Eisenberg <scott2@>wrote:
>>
>>> I never quite understood the advantage of salting in the same database
>>> next the password hash itself. It seems that when the hackers crack into
>>> the database they take the salt with the hash so the protection added is
>>> minimal.
>>>
>>> I suppose it protects when a hacker grabs it "over the wire" or maybe if
>>> the password is logged in a server log or something but the major thefts
>>> of
>>> info seem to be hacks directly into the database.
>>>
>>> Anyone can help me here?
>>>
>>> On Jul 23, 2012, at 8:34 AM, Joshua Kehn wrote:
>>>
>>>> You need to save the salt in the database.
>>>>
>>>> Regards,
>>>>
>>>> -Josh
>>>> ___________________________
>>>> http://joshuakehn.com
>>>> Currently mobile
>>>>
>>>> On Jul 23, 2012, at 8:29 AM, suryazi <suryazi@.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am using the Shiro plugin (Shiro 1.1.4) in my Grails application. I
>>> am
>>>>> using the below code to save the user in my bootstrap
>>>>>
>>>>> def user = new User(username: "User", passwordHash: new
>>>>> Sha512Hash("password").toHex())
>>>>> user.save()
>>>>>
>>>>> I am able to login into the system using the above credentials.
>>>>>
>>>>> My problem is after salting the password as below
>>>>>
>>>>> def user = new User(username: "User", passwordHash: *new
>>>>> Sha512Hash("password","User",1024)*.toHex())
>>>>> user.save()
>>>>>
>>>>> I am unable to logon and the system is showing invalid
>>> username/password
>>>>> message. Please let me know how to overcome it.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>> http://grails.1312388.n4.nabble.com/Salting-password-tp4632042.html
>>>>> Sent from the Grails - user mailing list archive at Nabble.com.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>> --
>> -Raphael Miranda
>> @raphaelom
>>
>
>
>
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Salting-password-tp4632042p4632261.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Andrew Todd

Re: Salting password

In reply to this post by suryazi

On Thu, Jul 26, 2012 at 3:59 AM, suryazi <[hidden email]> wrote:

This is a bad idea, encapsulating the worst of "security through
obscurity." You're essentially suggesting implementing a custom hash
algorithm for your usernames. If you don't understand why it's a bad
idea, I might suggest doing some fundamental security reading before
going further. Look up Bruce Schneier. Rule #1 of cryptography is
"don't roll your own."

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

suryazi

Re: Salting password

Seems you got me wrong. What I was suggesting is as we are adding salt to the password, we can make the password more complex by adding some additional attributes from our code to the given password and then hash it.

Quote

Why not we wrote some code in the front end itself to alter the password, e.g., creating an image of the username and adding it to the given password along with the generated salt and hash the password with the combination of these three attributes.

Unquote

As suggested, I will certainly try to look Bruce Schneier. Rule #1 of cryptography is
"don't roll your own."

Andrew Todd wrote

On Thu, Jul 26, 2012 at 3:59 AM, suryazi <[hidden email]> wrote:
> Well said. If the stored salt is the issue of concern then I would like to
> add new dimension to password hashing. Why not we wrote some code in the
> front end itself to alter the password, e.g., creating an image of the
> username and adding it to the given password along with the generated salt
> and hash the password with the combination of these three attributes. We
> just save the hash password and the salt into the DBRealm and will never
> disclose the image source code. When we need to authenticate we grab the
> username and process it to generate the image and add it to the given
> password along with salt from the DBRealm. Even if the hacker is having the
> salt and the password he cannot able to crack the password as the process
> of generating the image is embedded in the code itself and it will be hard
> to crack it. Further if we rehash the code multiple times using the above
> mentioned strategy then for sure it will give nightmares to the hackers or
> crytpoanalysis to find out the passwords. I would love to hear comments or
> suggestions to the suggested method.

This is a bad idea, encapsulating the worst of "security through
obscurity." You're essentially suggesting implementing a custom hash
algorithm for your usernames. If you don't understand why it's a bad
idea, I might suggest doing some fundamental security reading before
going further. Look up Bruce Schneier. Rule #1 of cryptography is
"don't roll your own."

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email