Encrypting Passwords

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

re: Encrypting Passwords

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

Cord-Heinrich Pahlmann schrieb:That's fine.
Where does this key come from in the first place?
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.
Where do all the passwords come from?
Your english is just fine

Regards
Stefan

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

iD8DBQFFnkfwyeCLzp/JKjARAjOBAKCQ/h96S53efCB1gHbzJpZB6bCWHwCghZLO
on5Z0CMNc74ysaIUZjwaxuY=
=oHGN
-----END PGP SIGNATURE-----

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:

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?
OK, I have to check into that. The source-code I use uses 128Bit key
which is ok I guess.
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?

re: Encrypting Passwords

Following on from Cord-Heinrich Pahlmann's message. . ./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.

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

re: Encrypting Passwords

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

re: Encrypting Passwords

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

Cord-Heinrich Pahlmann schrieb:I know exactly what you mean (There are password tools out there like
keepass ;) )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)

iD8DBQFFnnPvyeCLzp/JKjARArE9AJ9SzqpKivzV7UYMLWSNjpkjxNxeOACfebQZ
yYNBeA/pp3tA3Mcuer+YgGQ=
=WJGX
-----END PGP SIGNATURE-----

re: Encrypting Passwords

Following on from Cord-Heinrich Pahlmann's message. . .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.
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?
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@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>

re: Encrypting Passwords

Peter Fox schrieb:
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.
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

re: Encrypting Passwords

"Cord-Heinrich Pahlmann" <SPAM@Heineken2000.dewrote in message
news:1168000285.240787.131580@s34g2000cwa.googlegr oups.com...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-redi...=++%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.

re: Encrypting Passwords

>Now, as far as the technical matters ...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

re: Encrypting Passwords

Gordon Burditt wrote:
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.

re: Encrypting Passwords

"Gordon Burditt" <gordonb.olgg8@burditt.orgwrote in message
news:12q8o836pfg0i34@corp.supernews.com...You've gone mad. Cite an example where this is the case.

re: Encrypting Passwords

David T. Ashley schrieb:
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.

Thanks for the cause for thought. I will definitely implement this in
my project and all the future ones.
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.

re: Encrypting Passwords

Gordon Burditt schrieb:
Yep. I don't.
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.ThePageIWannaLoginTo" method="POST">
<input type="hidden" name="username" value="MyUsername">
<input type="hidden" name="password" value="MyClearTextPassword">
<input type="submit" value="Login">
</form>

re: Encrypting Passwords

Cord-Heinrich Pahlmann wrote:
As long as it's going over HTTP, instead of HTTPS - it's going
over the web unencrypted.

re: Encrypting Passwords

Sanders Kaufman schrieb:
I know that. But what if my webpage (script) uses HTTPS. My login to my
script is than secure.
But when I send the formular-data to a third-party-webpage (even when
it is HTTPS) will it be encrypted?
Send from https://mydomain --https://otherWebpage ?

re: Encrypting Passwords

Cord-Heinrich Pahlmann wrote:Yes. It will be encrypted - between sender and receiver.

re: Encrypting Passwords

Sanders Kaufman schrieb:

OK. Will the traffic be encrypted when I send to a HTTP address?of username and password.

re: Encrypting Passwords

Cord-Heinrich Pahlmann wrote:No, it will not.
--
Rik Wasmus

re: Encrypting Passwords

Cord-Heinrich Pahlmann wrote:That' can't happen.
In order for two systems to communicate, they have to use the
same protocol.

If that second system then forwards the data on over HTTP - it
will not be encrypted.