Passwords need to be hashed in SqlAlchemy

should tokens also be encrypted?

I would argue that any data that, in the event the backend (database) is compromised, would leak critical authentication data should be salted & hashed prior to storage. There would have to be a strong business case for storing them in plain text.

The configuration is not accessible throughout the application.Ie every where Options is being passed.Need to find an elegant way to make them available throughout the application.

Dolp: They all need to be hashed.That what I also feel.

Is there an open stack standard on how we manage sensitive information.If not we could start a discussion.

Also values once hashed,we cant get back the original value.So we cannot hash tokens as we pass the tokens to the user.They have to be encrypted

We pass the token to the user more than once?

-Dolph Mathews

On Jun 19, 2011, at 3:14 PM, yogirackspace<email address hidden> wrote:

> Also values once hashed,we cant get back the original value.So we cannot hash tokens as we pass the tokens to the user.They have to be encrypted
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/rackspace/keystone/issues/42#issuecomment-1398511

No, but services do a get on the token to validate it. But we may be able to still hash it. Can anyone think of a use case where we need to retrieve the token without having it? I can't off the top of my head right now...

Clients could make call to authenticate and retrieve the catalog and the token.They could make this call any number of times.Here they would be making the calls using their credentials.This is a case where we need to retrieve the token without having it.

Waiting for Jay to complete global conf access code.Then I could conditionally enable disable passwords.Need to make call on whether we need to encrypt tokens.

@jaypipes: assigning to you to track for when you think we can have a global config framework/lib.

No prob, Z.

@jaypipes: we had this scheduled for D3. We're out of time on that unless you have something to give us this week. Let me know, otherwise we move it to D4 or backlog?

D4, thx Z.

Done changes to hash and store passwords on the DB.Have also added config parameters to enable/disable password hashing and to pass a salt that could be used for hashing.

Pending merge.

kinda late to this thread - but isn't the recommend way to do salting of passwords to do a (random) salt per password instead of a global salt?

And why are we making hashing optional?

https://github.com/openstack/keystone/blob/master/keystone/backends/sqlalchemy/models.py#L131

Latest changes use Random salt.Git is yet to merge as the change has introduced new dependency.
Some felt that there could be people who want hashing to be disabled, if they are testing stuff locally.Default behavior is to have the value hashed.However there is an option to disable.

https://review.openstack.org/#change,719