Encrypting Passwords

[Cord-Heinrich Pahlmann]

Hi,

I have written a tool wich de/encrypts a few of my forum and
bloggin-Passwords.
My question is how secure it is.
The following describes how I have encrypted my passwords.

When I log in, the Login-Password is changed into a md5-Hash and is
compared to the login-password in the db. If the passwords are the same
the use is logged in (common procedure). Then the clear-text
login-password decrypts an unknown key which is stored in the
$_SESSION-Variable. With that key I decrypt the stored passwords in the
db.
I use the Blowfish Algorithm
(http://www.php-einfach.de/sonstiges_...ish_script.php,
Source is in German, sorry.).
How secure is the Blowfish Algorithm?
Each time I log in to my Site, the script generates a new key and
de/encrypts all the stored passwords again. So the stored
crypted-passwords look different everytime I login.

Sry, for my English-skills... I'm a little bit rusty...

[Stefan Rybacki]

Re: Encrypting Passwords

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cord-Heinrich Pahlmann schrieb:

Hi,
>
I have written a tool wich de/encrypts a few of my forum and
bloggin-Passwords.
My question is how secure it is.
The following describes how I have encrypted my passwords.
>
When I log in, the Login-Password is changed into a md5-Hash and is
compared to the login-password in the db.

That's fine.

If the passwords are the same
the use is logged in (common procedure). Then the clear-text
login-password decrypts an unknown key which is stored in the
$_SESSION-Variable.

Where does this key come from in the first place?

With that key I decrypt the stored passwords in the
db.
I use the Blowfish Algorithm
(http://www.php-einfach.de/sonstiges_...ish_script.php,
Source is in German, sorry.).
How secure is the Blowfish Algorithm?

The blowfish algorithm is as far as remember known as secure (means no
effective way of breaking it) as long as you use the full 16 rounds of
encryption.

Each time I log in to my Site, the script generates a new key and
de/encrypts all the stored passwords again. So the stored
crypted-passwords look different everytime I login.
>

Where do all the passwords come from?

Sry, for my English-skills... I'm a little bit rusty...

Your english is just fine

Regards
Stefan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)

iD8DBQFFnkfwyeC Lzp/JKjARAjOBAKCQ/h96S53efCB1gHbz JpZB6bCWHwCghZL O
on5Z0CMNc74ysaI UZjwaxuY=
=oHGN
-----END PGP SIGNATURE-----

[Cord-Heinrich Pahlmann]

Re: Encrypting Passwords

Hi Stefan, thx for the fast answer.
First of all I should define some constants to deconfuse (is that a
word?) some of the terms I use.
"A-Password" is the password the user uses to login to the webpage
"KEY" is a randomly generated 16char string which is the key to decrypt
the B-Passwords.
"B-Passwords" are the crypted passwords from the DB for the
third-party-logins.
"C-Passwords" are the decrypted B-Passwords
That should help

Stefan Rybacki schrieb:

Then the clear-text
login-password decrypts an unknown key which is stored in the
$_SESSION-Variable.

>
Where does this key come from in the first place?
>

Ok, that was a little bit confusing. The key is blowfish decrypted in
the DB. It is stored right next to the username and A-password of each
user. And that key is newly generated each time the user logs in.
I use the clear-text A-password to encrypt the key, so that I as the
Administrator can't decrypt the B-passwords from my friends (other
users).
Since md5 is a one-way decryption I have no chance to gather the
C-Passwords of any user, right?

How secure is the Blowfish Algorithm?

>
The blowfish algorithm is as far as remember known as secure (means no
effective way of breaking it) as long as you use the full 16 rounds of
encryption.

OK, I have to check into that. The source-code I use uses 128Bit key
which is ok I guess.

Each time I log in to my Site, the script generates a new key and
de/encrypts all the stored passwords again. So the stored
crypted-passwords look different everytime I login.

>
Where do all the passwords come from?

The user has to enter the C-Passwords and the other logindata. You can
fetch third-party formulars and the script automatically logs you into
the page.
How safe is it to send POST-Data to a third-party homepage. I wouldn't
really use this tool for my eMail or homebanking accounts but for forum
and blogpages it should be safe enough, right?

[Peter Fox]

Re: Encrypting Passwords

Following on from Cord-Heinrich Pahlmann's message. . .

>Hi,
>
>I have written a tool wich de/encrypts a few of my forum and
>bloggin-Passwords.
>My question is how secure it is.

/My/ question is how appropriate is it.

Whatever you do, _don't_ waste time worrying about the theoretical
breakability of proper cryptographic routines, they will be many times
stronger (unless badly misused) than other lines of attack.

Complexity is your enemy not your friend. Each protective element must
have a purpose, be used appropriately with its weaknesses understood.
One good lock is generally better than two feeble ones.

I haven't quite understood the details of your scheme. What exactly are
you trying to encrypt and why? What's the point of the second part? -
The words "decrypting stored passwords" alarms me.

>The following describes how I have encrypted my passwords.
>
>When I log in, the Login-Password is changed into a md5-Hash and is
>compared to the login-password in the db. If the passwords are the same
>the use is logged in (common procedure). Then the clear-text
>login-password decrypts an unknown key which is stored in the
>$_SESSION-Variable. With that key I decrypt the stored passwords in the
>db.
>I use the Blowfish Algorithm
>(http://www.php-einfach.de/sonstiges_...ish_script.php,
>Source is in German, sorry.).
>How secure is the Blowfish Algorithm?
>Each time I log in to my Site, the script generates a new key and
>de/encrypts all the stored passwords again. So the stored
>crypted-passwords look different everytime I login.
>
>Sry, for my English-skills... I'm a little bit rusty...
>

--
PETER FOX Not the same since the bra business went bust
peterfox@eminen t.demon.co.uk.n ot.this.bit.no. html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.dem on.co.uk>

[Cord-Heinrich Pahlmann]

Re: Encrypting Passwords

Peter Fox schrieb:

I haven't quite understood the details of your scheme. What exactly are
you trying to encrypt and why? What's the point of the second part? -
The words "decrypting stored passwords" alarms me.

Who doesn't know the problem. You want to create a thread in a forum or
a blog and have forgotten your login-data. Thats where my script is
supposed to help (me and some friends).
The script generates the login-formular of the forum or blog and
automatically fills in your login-data (username and password) and
POSTs the data to the remote site.
That is why I store crypted passwords in my DB.
Since I don't want to be ABLE to decrypt any passwords from my friends
I use following schema:
The crypted passwords are in the DB. To decrypt these passwords you
need a KEY. This Key is also crypted in the DB. Only the cleartext
password of the user (loginpassword for my page) can decrypt that KEY.
So I make three steps in order to decrypt a login-password for a forum.
User goes to my page -Logs in -the clear-text pass decrypts the KEY
(user dependent) -the KEY can decrypt any of the users forum or
blog-passwords.

Is that understandable. I can't to better with my english skills, sorry.

[Stefan Rybacki]

Re: Encrypting Passwords

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cord-Heinrich Pahlmann schrieb:

Peter Fox schrieb:
>
>...
>
Who doesn't know the problem. You want to create a thread in a forum or
a blog and have forgotten your login-data. Thats where my script is
supposed to help (me and some friends).

I know exactly what you mean (There are password tools out there like
keepass ;) )

>...
>
Is that understandable. I can't to better with my english skills, sorry.
>

It's understandable, but let me tell you, that if you want to you could
decrypt all your friends password just by storing their A-password
whenever they login or by storing their B-passwords before you encrypt
them or after you decrypted them for displaying or sending. This is just
to mention, because you're trying so hard where in the end they have to
trust you anyways ;) (Just my two cents)
According to your other question about whether it's save to send those
passwords using POST to other websites. IMHO it's as save as it would be
from the original website.

Regards
Stefan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)

iD8DBQFFnnPvyeC Lzp/JKjARArE9AJ9Szq pKivzV7UYMLWSNj pkjxNxeOACfebQZ
yYNBeA/pp3tA3Mcuer+YgG Q=
=WJGX
-----END PGP SIGNATURE-----

[Peter Fox]

Re: Encrypting Passwords

Following on from Cord-Heinrich Pahlmann's message. . .

>Peter Fox schrieb:
>

>I haven't quite understood the details of your scheme. What exactly are
>you trying to encrypt and why? What's the point of the second part? -
>The words "decrypting stored passwords" alarms me.

>
>Who doesn't know the problem. You want to create a thread in a forum or
>a blog and have forgotten your login-data. Thats where my script is
>supposed to help (me and some friends).
>The script generates the login-formular of the forum or blog and
>automaticall y fills in your login-data (username and password) and
>POSTs the data to the remote site.
>That is why I store crypted passwords in my DB.

Ouch!
If all you're doing is implementing a forgotten password get-out then
this is far too complex and worrying.

The scheme you use is
1
An unvalidated user confesses to forgetting password

2
Your system _generates a new password_ ...
.... hashes it and stores as normal
.... sends it to the email address

What you have now done is made the login authorisation utterly separate
from the any other special key.

>Since I don't want to be ABLE to decrypt any passwords from my friends
>I use following schema:
>The crypted passwords are in the DB. To decrypt these passwords you
>need a KEY. This Key is also crypted in the DB. Only the cleartext
>password of the user (loginpassword for my page) can decrypt that KEY.
>So I make three steps in order to decrypt a login-password for a forum.
>User goes to my page -Logs in -the clear-text pass decrypts the KEY
>(user dependent) -the KEY can decrypt any of the users forum or
>blog-passwords.

Suppose a user wants to keep something secret from you (as the DB
admin), they need to provide a key that you can't possibly forge, AND
they need some magic way of getting it out of your system and down the
line /before/ you can intercept it. Not really possible unless the data
is encrypted at their end and decrypted at their end.

(What they /can/ do is prove they are in possession of a working key
without handing it over to you. But that is another story.)

I think you need to may need to rethink your security model. Why are
there lots of passwords? Surely you would have a simpler system if you
had rules for which *validated* user could do what thing. This is easy
to set up and administer. Why do they need to provide yet another
secret (with all the hassle that you're finding out about the hard way)
when you know who they are and what they're entitled to do?

>
>Is that understandable. I can't to better with my english skills, sorry.

Don't worry about your English, it is fine. (But your explanation is
still confusing me a bit.)

Umm.


--
PETER FOX Not the same since the adhesive company came unstuck
peterfox@eminen t.demon.co.uk.n ot.this.bit.no. html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.dem on.co.uk>

[Cord-Heinrich Pahlmann]

Re: Encrypting Passwords


Peter Fox schrieb:

Ouch!
If all you're doing is implementing a forgotten password get-out then
this is far too complex and worrying.

Nope. I just want to have a tool which remembers all my passwords for
all the different forums I use. And I want to access them whereever I
am.

I think you need to may need to rethink your security model. Why are
there lots of passwords? Surely you would have a simpler system if you
had rules for which *validated* user could do what thing. This is easy
to set up and administer. Why do they need to provide yet another
secret (with all the hassle that you're finding out about the hard way)
when you know who they are and what they're entitled to do?

If my google-groups password would be Hg#&5d16Hgsd I would not be able
to remember it. Thats why I store this password (along with a lot of
other forum passwords) crypted in the DB.
The only reason why I have that second instance (with the secret KEY ->
nobody knows) is that I don't want to store the
clear-text-login-password (to my script) in the $_SESSION-Variable.

I hope that the following jpg clearly show what my intentions are.

http://www.pahlmann.biz/org.jpg

[David T. Ashley]

Re: Encrypting Passwords

"Cord-Heinrich Pahlmann" <SPAM@Heineken2 000.dewrote in message
news:1168000285 .240787.131580@ s34g2000cwa.goo glegroups.com.. .

Hi,
>
I have written a tool wich de/encrypts a few of my forum and
bloggin-Passwords.
My question is how secure it is.
The following describes how I have encrypted my passwords.
>
When I log in, the Login-Password is changed into a md5-Hash and is
compared to the login-password in the db. If the passwords are the same
the use is logged in (common procedure). Then the clear-text
login-password decrypts an unknown key which is stored in the
$_SESSION-Variable. With that key I decrypt the stored passwords in the
db.
I use the Blowfish Algorithm
(http://www.php-einfach.de/sonstiges_...ish_script.php,
Source is in German, sorry.).
How secure is the Blowfish Algorithm?
Each time I log in to my Site, the script generates a new key and
de/encrypts all the stored passwords again. So the stored
crypted-passwords look different everytime I login.
>
Sry, for my English-skills... I'm a little bit rusty...

Well, in English, that last paragraph is called "fishing for compliments".
You secretly know your English is just fine, and you secretly want us to say
that.

Your English is just fine.

Now, as far as the technical matters ...

The scheme you've presented goes against known best practices.

First, I would recommend SHA1 over MD5. There have been several successful
partial attacks on MD5, see:

http://www.wikipedia.org/search-redirect.php?search=MD5&language=en&go=++%3E++&go=Go

MD5 and SHA1 are functionally equivalent from your point of view, in that
(a)PHP supports both, and (b)SHA1 is 160 bits rather than 128 bits (so, you
need to store a few more hexadecimal characters).

STORAGE OF PASSWORDS:

Modern doctrine is that passwords are NEVER stored plain or in a reversible
way. The hash that you store should be the hash of the concatenation of:

a)A key known only to the server (500 characters of random text in a file is
fine).

b)The password.

c)And (a) and (b) should be repeated a few times, i.e. A + B + A + B + A + B
+ A, at least.

In order for an attacker to do anything, it is required that:

a)The key be compromised.

b)The stored hash be compromised.

c)The algorithm be compromised (although concatenation and hashing isn't
hard to guess).

d)And even once that condition is met, the best that can be mounted is a
dictionary attack.

LOST PASSWORDS:

As another poster pointed out, best practice is to reset the password to a
random new one and e-mail it to the user. A good system is to keep two
passwords (permanent + timed temporary) so that one user can't disable
another's account by using the "lost password" functionality. He can only
generate nuisance e-mail.

The user shouldn't be "stuck" with the random password, he should then be
able to change it.

Dave.

[Gordon Burditt]

Re: Encrypting Passwords

>Now, as far as the technical matters ...

>
>The scheme you've presented goes against known best practices.

Known best practices include:
Don't store the passwords in plain text or reversible encryption.
Don't transmit passwords in the clear over the network.

Unfortunately, with many protocols, you can't have both.
Challenge-response protocols may require that you have the actual
password, not a hash of it, on both sides to perform the
challenge-response.

Gordon L. Burditt

[Sanders Kaufman]

Re: Encrypting Passwords

Gordon Burditt wrote:

Unfortunately, with many protocols, you can't have both.
Challenge-response protocols may require that you have the actual
password, not a hash of it, on both sides to perform the
challenge-response.

That's the OSI model at work there.
If you're not secure at the low levels, you're fooling yourself
to think your secure at the high levels.

[David T. Ashley]

Re: Encrypting Passwords

"Gordon Burditt" <gordonb.olgg8@ burditt.orgwrot e in message
news:12q8o836pf g0i34@corp.supe rnews.com...

Now, as far as the technical matters ...
>>
>>The scheme you've presented goes against known best practices.

>
Known best practices include:
Don't store the passwords in plain text or reversible encryption.
Don't transmit passwords in the clear over the network.
>
Unfortunately, with many protocols, you can't have both.
Challenge-response protocols may require that you have the actual
password, not a hash of it, on both sides to perform the
challenge-response.

You've gone mad. Cite an example where this is the case.

[Cord-Heinrich Pahlmann]

Re: Encrypting Passwords


David T. Ashley schrieb:

Well, in English, that last paragraph is called "fishing for compliments".
You secretly know your English is just fine, and you secretly want us to say
that.
>
Your English is just fine.

I think my English is OK, but it is not good enough to explain my
script the way I wanted to.
See below. I have to explain a lot of things because I couldn't get it
right the first time.

STORAGE OF PASSWORDS:
>
Modern doctrine is that passwords are NEVER stored plain or in a reversible
way. The hash that you store should be the hash of the concatenation of:
>
a)A key known only to the server (500 characters of random text in a file is
fine).
>
b)The password.
>
c)And (a) and (b) should be repeated a few times, i.e. A + B + A + B + A + B
+ A, at least.
>
In order for an attacker to do anything, it is required that:
>
a)The key be compromised.
>
b)The stored hash be compromised.
>
c)The algorithm be compromised (although concatenation and hashing isn't
hard to guess).
>
d)And even once that condition is met, the best that can be mounted is a
dictionary attack.
>

Thanks for the cause for thought. I will definitely implement this in
my project and all the future ones.

LOST PASSWORDS:
>
As another poster pointed out, best practice is to reset the password to a
random new one and e-mail it to the user. A good system is to keep two
passwords (permanent + timed temporary) so that one user can't disable
another's account by using the "lost password" functionality. He can only
generate nuisance e-mail.
>
The user shouldn't be "stuck" with the random password, he should then be
able to change it.

I realize that. Thats how I programmed all my web applications. I'm
always annoyed when I forget a password and get my real password send
back from a webapplication (shows that they probably store my password
in clear-text in their db).

But that's not the point of my script. I doesn't help me not to forget
my passwords (I can retrieve them from the third-party webpage if I
forget it). It is supposed to get me access to all the forum- and
blog-pages (whereever I am). And it loggs me into those pages.

[Cord-Heinrich Pahlmann]

Re: Encrypting Passwords


Gordon Burditt schrieb:

Known best practices include:
Don't store the passwords in plain text or reversible encryption.

Yep. I don't.

Don't transmit passwords in the clear over the network.

That's something I do.
Question: Does it make a difference if I type my password into a
password-formular of a webpage or if my script computes the whole
login-form (so the password will be there, too) and then sends it via
POST to the webpage?

It would look like this:
<form action="http://www.ThePageIWan naLoginTo" method="POST">
<input type="hidden" name="username" value="MyUserna me">
<input type="hidden" name="password" value="MyClearT extPassword">
<input type="submit" value="Login">
</form>

[Sanders Kaufman]

Re: Encrypting Passwords

Cord-Heinrich Pahlmann wrote:

Question: Does it make a difference if I type my password into a
password-formular of a webpage or if my script computes the whole
login-form (so the password will be there, too) and then sends it via
POST to the webpage?

As long as it's going over HTTP, instead of HTTPS - it's going
over the web unencrypted.