Re: Password Logic

-Original Message- From: Matt Liotta [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Date: Mon, 5 Jan 2004 10:25:27 -0500 Subject: Re: Password Logic but you only need the public key for password verification (eg encrypt th epassword again and verify the encrypted data). Only selected

RE: Password Logic

in question most of the time anyways (like wife's name, first child, the dog etc). Jesse -Original Message- From: Matt Robertson [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Date: Mon, 5 Jan 2004 07:59:15 -0800 Subject: RE: Password Logic Mauricio's system is definitely a cut above many

RE: Password Logic

I have an SP for generating a password based on a username and a 'seed' which will generate a random password which is unique for that user. _ From: Jesse Houwing [mailto:[EMAIL PROTECTED] Sent: 06 January 2004 10:01 To: CF-Talk Subject: RE: Password Logic You can also generate a random

RE: Password Logic

A plaintext link or URL is no more or less secure than a plaintext password. The equivalent using the random password technique would simply involve making the new random password only good for 24 hours. Assuming the UUID is truly random (historically some versions of CF have generated

Re: Password Logic

I would not suggest storing your passwords in plain text in the DB.Storing them in this manner leaves them vulnerable to anyone who ends up with access to that database.You may or may not consider the data in your web app important to your user, but most users will attempt to use a

RE: Password Logic

Cameron Childress said: A plaintext link or URL is no more or less secure than a plaintext password. The equivalent using the random password technique would simply involve making the new random password only good for 24 hours. Assuming the UUID is truly random (historically some versions of

Re: Password Logic

You could use encryption with a private and a public key. In the application you always re-encrypt the password and compare the encrypted string. And in certain cases someone from another system can use the private key to extract the password. This would be the best of both worlds,

Re: Password Logic

to the same database. Jesse -Original Message- From: Matt Liotta [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Date: Mon, 5 Jan 2004 09:32:11 -0500 Subject: Re: Password Logic You could use encryption with a private and a public key. In the application you always re-encrypt the password

Re: Password Logic

: Password Logic Wherever possible we try to use an e-mail address as the username and then generate a password and e-mail it to the user. That way, they are guaranteed to give you a valid address as they can't get in without one... It also covers the uniqueness angle as an e-mail address is unique

Re: Password Logic

but you only need the public key for password verification (eg encrypt th epassword again and verify the encrypted data). Only selected personel would have access to the private key in case anything needs to be decrypted. This could also happen from an intranet system that has access to

RE: Password Logic

Mauricio's system is definitely a cut above many others, but as was pointed out it has a weakness.The email goes to a unique address, but you can't gaurantee the recipient is the actual user.You need to authenticate the person and not the address to take this a step further. I use the same system

RE: Password Logic

Joining the thread late here, so I apologize if this isn't quite on topic... The problem with requiring any sort of question, but especially requiring the user to pick from a list of common questions, is that the answers are not secure.With a little effort, you can uncover people's social

Password Logic

I want to enable users of my web app, upon creating their accounts, to be able to select their own login password. When they create their account, I'm comparing their proposed password with all other passwords stored in a db to ensure that the proposed password is unique. If it's not, though, I

RE: Password Logic

Wherever possible we try to use an e-mail address as the username and then generate a password and e-mail it to the user. That way, they are guaranteed to give you a valid address as they can't get in without one... It also covers the uniqueness angle as an e-mail address is unique. Once the user

Re: Password Logic

Why do you care if the password is unique? Wouldn't your time be better spent making sure the password is mixed case with letters and numbers so it can't be easily guessed? Or perhaps you should write something that would de-activate the account if the user types in the wrong password more

RE: Password Logic

:858.509.3098 aim:cameroncf email: [EMAIL PROTECTED] -Original Message- From: Bob Haroche [mailto:[EMAIL PROTECTED] Sent: Sunday, January 04, 2004 9:00 PM To: CF-Talk Subject: Password Logic I want to enable users of my web app, upon creating their accounts, to be able to select their own login

Re: Password Logic

I would not suggest storing your passwords in plain text in the DB.  Storing them in this manner leaves them vulnerable to anyone who ends up with access to that database.  You may or may not consider the data in your web app important to your user, but most users will attempt to use a

Re: Password Logic

Cameron Childress wrote: Phew, that was a long answer Yes, and very useful as are the other responses. That's what I was looking for. I already have the random, strong password generation part down. I wasn't going to hash the password because the web app info really isn't terribly private

Re: Password Logic

That's right, you can't un-hash a stored variable. For best practices-sake, if the user forgets their password, you should only be able to generate a new one and email it out, and let the user change it to something else. -w At 10:46 PM 1/4/2004, you wrote: Cameron Childress wrote: Phew,

RE: Password Logic

Yes, and very useful as are the other responses. That's what I was looking for. Glad I could help. And if I understand it correctly, you can't un-hash a stored variable to read it, but can only compare a hashed Form.Password variable against what's stored in the db. Is that right? Yup.

Did Macromedia publish your password? (was RE: Password Logic)

One of the most frequently seen security vulnerabilities on the internet today is a web application that will email you your password in plaintext. Speaking of...A quick rant here... Went to MAX this year.Got my registration packet and looked as my session summary.As they have done in the

Re: Password Logic

| Certainly storing hashes is better than passwords. However, you can't | reverse hashes, which means that if someone forgets their password you | can't figure it out for them. For some web applications that is a | problem although I think offering to reset the password provides the | same