Hi,
I have a password column in my customer table. Right now, the
scaffolding saves the passsword in plain text. If I wanted to store
the password in an encrypted form, what is the easiest way of doing
that?
Much thanks, - Dave
Hi,
I have a password column in my customer table. Right now, the
scaffolding saves the passsword in plain text. If I wanted to store
the password in an encrypted form, what is the easiest way of doing
that?
Much thanks, - Dave
Have a look at what acts_as_authenticated/restful_authentication does.
On Jan 18, 2008 9:32 AM, [email protected] <
[email protected]> wrote:
–
Ryan B.
Feel free to add me to MSN and/or GTalk as this email.
Ditto on the plugins Ryan mentioned. It’s important to note that you
shouldn’t store the encrypted password – instead, you should store a
salted hash, which is much more secure. There are lots of resources that
discuss how and why.
I would recommend the same, except SHA256 instead of the SHA1 that
restful authentication uses.
Those plugins generate code that you can put anywhere. If you want to
keep an existing table, you could add all of restful_authentication’s
fields to that table and just copy the generated User model code into
your Customer model. Or, it might be easier to do it the other way
around.
On Jan 18, 3:09 pm, “[email protected]”
I like this idea (doing it the other way around, that is).
I have a follow up question on the subject of encryption/salted
hashes. If I want to (for lack of a better word) encrypt some of the
other fields in the database, can I use the plugin(s) above to do
that? Otherwise, how would you recommend I get it done?
Thanks, - Dave
Regarding the resultful_authentication (since it seems
acts_as_authenticated is deprecated), how would I configure my app so
that restful_authentication uses an existing table I have (customer)
with its fields (customer.username, customer.password)?
Thanks, - Dave
You could use the same methods in those plugins. The way it works is
the data is run through a one-way hashing function. You store this
hash in the database. Of future requests, you must hash the user input
then compare it to the hash you have in the database. It’s one way
though, so there is no feasible way to know what the original data was
On Jan 18, 4:58 pm, “[email protected]”
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs