what i have done is as follows password = Digest::SHA1.hexdigest("#{salt}:#{password}")
pass1 = Digest::SHA1.hexdigest("#{salt}:asdfgh") pass2 = Digest::SHA1.hexdigest("#{salt}:asdfgh") pass3 = Digest::SHA1.hexdigest("#{salt}:qwerty")
puts pass1==pass2 puts pass1==pass3
This works fine but i need to get the decrypted password
how can i get it any help is highly appreciated
Thanks in advance
Krishnaprasad Varma India
what i have done is as follows password = Digest::SHA1.hexdigest("#{salt}:#{password}")
pass1 = Digest::SHA1.hexdigest("#{salt}:asdfgh") pass2 = Digest::SHA1.hexdigest("#{salt}:asdfgh") pass3 = Digest::SHA1.hexdigest("#{salt}:qwerty")
puts pass1==pass2 puts pass1==pass3
This works fine but i need to get the decrypted password
how can i get it
You can't[1]. Digests by design are one way only.
Fred
[1] Obviously you can try a brute force attack and cryptography
researchers have found various attacks, but that's probably not what
you meant
And using Digest::MD5 ?? can i encrypt
Why do you need the plaintext?
Generally speaking, even an admin should not be able to get back your plaintext. That role should be able to reset your account so that you can once again set your password to something only you know.
To try and engineer something in that appears like security to a user but isn't is deceptive at best.
Digests are all one way. pretty much the definition of a digest is that it is not reversible.
Fred
Ok i think its time to reveal my need
i was doin a login system in rails for the time being i didnt provide the password encryption and i thought it was simple as many reliable encryption algorithms are available every where
every thing worked perfectly untill i started encrypting the password and save it in db
i am able to check weather the password enter is correct or not
almost all the browser provide the facility to remember username and passwords so i thought i would do it myself and stored the password and username in the cookie if " remember me " option is ticked
it now fetches the password from the database and stores it in the coockie so when the user comes next time he is shown the password which is encrypted and the login fails
Typically this is done by storing a token in a cookie - if your login page receives a cookie with an appropriate token then you skip straight to the user being logged in. This avoids needing to store the password in an insecure place.
Fred
Apologies if this seems a bit harsh, but you're not the first person to ask this list a question like this (and prolly not the last).
Security- especially cryptography is HARD. You clearly have no idea what you're doing when it comes to security/crypto. Even if you properly understood crypto fundamentals, you'd still probably use the algorithms incorrectly which would open up huge holes- it happens all the time. Even the so-called "experts" can and do get it wrong occasionally.
The solution is simple: stop trying to roll your own solution. Use SSL with something like restful_authentication and be done with it.
Wow, that is about the worst possible solution to the "keeping the user logged in" problem!
I assume you want them to be "just logged in" when they come back to the site? That is what the user wants. You can use a cookie to associate the user with being logged in, but why in the name of all good things would you want to store the username/password in the cookie? You know that is plain text? Your site, if it decides to let a user in for some reason other than user name and password really does not need to know anything about the password or user name. The session cookie is enough.
As others have said: you cannot "unhash" a cryptographic hash. Nor should you want to. The idea is to verify that the user knows the SECRET (password) without anybody else having access to the SECRET. Storing it in the cookie is bad.
You are trying to solve a very simple problem in a very complicated way!
Brendon.
He's still doing it better than the dev shop I once cleaned up after - they appeared to think that base64 encoding was a form of encryption...
Although, it did save me a lot of trouble when migrating users over to the new system.
--Matt Jones
We've got the same thing where I am at the moment. The old .net app has the passwords stored in plain text in the Db. I guess if you get as far as being able to log onto the db, then you have already gotten full access to the system, but still seems wrong.
Simon
The risk of to the users of access to plain text passwords is far greater, since many (most) users use the same password for similar types of sites. (I say that hoping people use a different password for online banking while they use another password for gmail, yahoo, <your system>, NYT, etc.)
Next up, support having to ask customers for the password to access the account!