Password retrieval

rocketman

Following the instructions in various posts, I got my system to handle forgotten passswords to the point of sending the password vial email. The result I got in the email was as follows:

Dear Maurice Bent

You recently requested a password retrieval from the club database. Your current password is @@BAS_PASSWORD@@

Please do not reply to this email. It has been sent from an unattended mailbox. Replies will not be monitored or responded to.

The ForgottenPassword email was formulated as follows (Message attrib - plain text set to html type:

Dear <<Members.FirstName>> <<Members.Surname>>
<p>
You recently requested a password retrieval from the club database. Your current password is <<Members.Password>>

Please do not reply to this email. It has been sent from an unattended mailbox. Replies will not be monitored or responded to.

What did I do wrong???

V4.7 build 1229

aware_support

You cannot use "Password" attribute directly if you want to display it in clear form. This attribute is encrypted and you will never be able to display its true value.

So what you should do is keep a copy of the password in a different attribute, called, for example "ClearPasssword". When the password is set, you should set the value of the "ClearPassword" attribute, not the "Password" attribute. You should have a rule that would copy the value of the "ClearPassword" attribute into the "Password" attribute (this would automatically encrypt the value). Login will work with the "Password" attribute as usual, but your e-mail will display the "ClearPassword" attribute.

Note, that storing a password in a clear format and then displaying it is not secure. A better approach would be not to display the current password to the user, but to generate random password on the fly, display it to the user, copy it into the "Password" attribute and then delete its value. You should ask the user to login with the random password and then change it.

rocketman

OK - that all makes sense. Tx for the tip

ACDC

I am having a problem understanding the present encryption of the password. The password is encrypted in the database, but the login form accepts the encrypted string which nullifies the encryption purpose

When I retrieve a password <<customer.password>> in a forgotten password scenario, I get the 32 bit encrypted number as apposed to the @@BAS_PASSWORD@@ as indicate previously in this thread

If Icopy and paste (from the email or directly out of the database) this number into the password login, it accepts it and logs me in .

Therefore the encrypted password in the database is just another representation of the password and is not a secure encryption

Could someone clarify this

aware_support

The password will be automatically encrypted when you set into the predefined Password attribute of the RegularUser object. If you want to maintain the "clear" password, you should use a separate attribute. Therefore, you will have two attributes - clear password and regular password. The user will be entering the value of the clear password, which you will then copy to the Password attribute by rules. The value of the clear password should then be used in your e-mails with the user.

ACDC

I understand the first part,

but what about the fact that the password technically is not encrypted.

The login should not accept the encrypted number as a password

ACDC

Maybe I should have started a new thread called "Password Not Encrypted"

The current password in RegularUser is technically not encrypted because the login accepts the encrypted number as a suitable password when it should not. It should only accept the unencrypted password and then compare it with the encrypted number in terms of the encryption algorithm

To test this, copy the encrypted number from the database and insert it into the login form as the password.

The password is still in the clear, but in a different representation

aware_support

Not sure I understand what you mean. The login will accept any value - it obviously assumes that the entered value is not encrypted and encrypts it.

ACDC

If a password is stored in an encrypted format in the database, then one should not be able to use the 32bit encrypted number to login

Going along the lines of maintaining a secure password in the database, the encrypted password is only secure if it is meaningless to all except the server authentication process.Otherwise whats the purpose of encryption?

As a test, If you copy the 32 bit encrypted number from the database table and use it as the password when you login, the system accepts it as a valid password.This is wrong, it should reject it and only allow the unencrypted password.

Therefore the password authentication process invalidates the encryption and makes what is perceived to be secure a password insecure

I hope I am making sense, because in my mind this is a serious problem

aware_support

Aware IM DOES NOT accept an encrypted number if you copy it from the database!

ACDC

I beg to differ

I am using update 1229 on a MySql 5.0 database

With a suitable DB editor, please go into the basdb database of an example application and find the admin record in the table "RegularUser"

Now go to the password attribute, encrypted 32 bit number and copy and paste it into the login form of that application and login as admin. This will prove what I am saying, the login will accept the 32 bit number as a valid password thus compromising the so called encrypted password and perceived security of the password

I would hate to think my system is the only system that does this. Could someone else give this a bash and confirm. I doubt it has anything to do with MySQL

ab042

I tried it and get "Invalid credentials or access denied. Please try again"

Everything appears to be working as it should, NO SECURITY ISSUE HERE.

ACDC

ab042

Could you confirm what database and version you are using and what DB tool you use to view and copy the encrypted password with

I need to get to the bottom of this, and identify where the issue is as I am sure I am not the only one. Its obviously a set of circumstances that promote this which means there IS A SECURITY ISSUE HERE

ab042

4.0 - 1147 MySql 5.0.67 MySqladmin 1.2.14 Does NOT have an issue

rocketman

Hmmm Aware support - there does seem to be a problem

Build 1243, Mysql V5.046 Community

I grabbed this number from the database using MsqlAdmin 9553eee1ef7f76fd7e62f0ecdc67f45d (I've scrambled the numbers for security). This is my encrypted password into the gliding club database.

I then called up the login screen using LogonOp?domain= *******

entered my user name, pasted the above number into the password field and it let me straight in

rocketman

Addendum.

To eliminate any possible Mysql issue, I typed the hex code directly into the password field. Again - Aware let me straight in

aware_support

Bug confirmed. Will be fixed in the next build.

aware_support

This should be fixed in version 4.8