|
|
Posted by Peter Fox on 01/05/07 17:21
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
>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.
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@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>
Navigation:
[Reply to this message]
|