Can we decrypt the cipher encrypted using Digest::SHA1.hexdigest

Rails
1

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 V.
India

2

On 21 Apr 2009, at 13:34, — Z@m — wrote:

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

3

And using Digest::MD5 ?? can i encrypt

4

On Apr 21, 2:22 pm, “Z@M” [email protected] wrote:

And using Digest::MD5 ?? can i encrypt

Digests are all one way. pretty much the definition of a digest is
that it is not reversible.

Fred

5

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.

6

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

7

On Tue, Apr 21, 2009 at 7:54 AM, Z@M [email protected]
wrote:

so when the user comes next time he is shown the password which is
encrypted and the login fails

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.

–
Aaron T.
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix &
Windows
Those who would give up essential Liberty, to purchase a little
temporary
Safety, deserve neither Liberty nor Safety.
– Benjamin Franklin

8

On Apr 21, 3:54 pm, “Z@M” [email protected] wrote:

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

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

9

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.

10

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 J.

11

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,
, NYT, etc.)

Next up, support having to ask customers for the password to access
the account!

12

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