If i Remove Security.salt and Security.cipherSeed value then Admin login not working.
Configure::write('Security.salt', '');
Configure::write('Security.cipherSeed', '');
Please Help
Of course the Admin login will not work. The AuthComponent needs that Strings to hash the User Data in the Session, as well for persisting passwords on the database.
Since you already have the passwords hashed on your databese, when you submit the admin login form, it will hash the password you just sent via input and compare with the database one to see if they match, if they do, permission is granted.
Considering that you deleted the salt, the hash will now have a different behavior compared to one with a provided salt, thus, it will output different hashes for the same input, which means permission is denied and will remain like this until you come back to the exact same salt.
When you bake a project with the cake bake command, it will generate and replace the default salts for you.
Remember, when you change this salts, every single password stored in the database will need to be rehashed, then you need to provide your users a way to do this, like a 'forgot my password' mechanism.
NOTE: This might appear as a optional step, but it is more like a "Must do" Configuration, and it should be done just after install. Remember that using an wide know Salt is a HUGE security flaw.
Related
I was debugging a Joomla site that had it's Super User password forgotten. The solution that I found was logging in to the database and changing the password field in the user table to:
d2064d358136996bd22421584a7cb33e:trd7TvKHx6dMeoMmBVxYmg0vuXEA4199
which is the hash for "secret". So far so good, however, I thought that the hash function takes the password and concatenates it with something else, either the username or a salt string or both and then spits out the hash code. To my surprise the above scenario worked so is it safe to conclude the Joomla only hashes the password itself without adding anything else to it?
Since you saved directly in the database what happened is that the string was effectively '' so it's not that there is no salt, it is that the salt is an empty string. Joomla knows how to handle salts and an empty string is just a special case of a salt, one you should only use temporarily in order to regain access to your site. It's much better to use the root user function since that puts up a big notice reminding you to undo it.
If I understand correctly, the biggest problem with sending a password via email is that it requires the password to be stored in clear text in the database. If the DB is compromised, the attackers will gain access to all accounts.
Is there a workaround for this problem?
How can one make sending a user their password via email as safe as possible?
The simple answer is: don't. If you think your database is insecure, an email is far, far less.
If you mean that you want to send them their password when they register, then you could do that before you store it in the database.
If you mean after they have registered, the only option is to store in plaintext (again, don't do this) or make a new, random password and send them that. It is impossible to get their password from the hash, which is why it makes the password storage safer. The best option is to generate a new (temporary) password you send them, or a token giving them access to a password change system.
You may want to consider a good hashing algorithm like BCrypt that includes a salt.
I don't know if my suggestion is feasible for your scenario, but you should better keep the data hashed or encrypted and send password reset links instead of plain-text passwords.
The moment the password is in cleartext in the email, it is inherently insecure.
As such, there is no safe way to send a password in cleartext safely.
You should not be storing passwords in cleartext in your database - you should be using salted hashes. When the user enters their password, you hash it with the salt and compare to the stored hash.
When people forget their password, instead of sending passwords by email, you should send reset links backed up by expiring tokens. These would generate a temporary new password (that would expire within minutes).
You should be hashing all passwords in your database.
sha1($_POST['password'].$salt.$username);
In the case of a lost password
A user requests a password reset link, which contains a hash generated in the "user_meta" table. When the user recieves this link, the hash is compared to that in the database, and the user will be able to UPDATE their current password with a new password.
The PTXT of the password is never reveiled.
You only compare hashes.
Yes, there is a common workaround.
Assuming that you have your users in your database.
You send the "password reset link" containing some "key" information, like a guid. An example link is a form:
http://your.site.com/setpassword?id=5b070092-4be8-4f4d-9952-1b915837d10f
In your database you store the mapping between sent guids and emails.
When someone opens your link, you check your database and you can find out who asks for the page - because any valid guid maps to an email. You can then safely let the user change his/her password assuming their email is not compromised.
When it's about to store the password, you never store it in plain text, you always hash passwords, using additional random salt to make the dictionary attack more difficult when someone breaks into your database.
There is a workaround which is less secure than a password reset but works if it is a requirement that users are sent a password, not a reset link.
What you do is you generate a new password that contains sufficient randomness to be very hard to guess, but is also formatted in a way that it is easy for them to remember and read out (say over the phone).
Something like: xyz-xyz-xyz-nnnn where xyz is an easy-to-spell but uncommon word and nnnn is a four digit number.
Then set it up so that this is a temporary password that needs to be changed on first login.
Set the password using the same logic you would use to set a normal password, so that it is correctly salted and hashed, and then send the password plaintext via email, like so.
Dear FirstName LastName,
You requested we reset your password.
Your new password is:
insipid-mirth-nonplus-9174
You will be able to log into the system once using this password, then you will need to enter a new password.
Important Caveats
This system has some serious vulnerabilities which make it unsuitable for websites where data security is crucial. There are more than these, but these are the ones I know/can think of:
Unlike systems which use a password reset link, this system could be used to lock someone out of the system (assuming you use it as is) unless you either require someone to fill out identifiable information before issuing the password reset, or send a "are you sure you want to reset your password?" email first. This would entail them clicking on a link with a GUID that goes to the server; at that point they may as well be sent to the password reset form anyway.
Since the password is being sent plain text via email, there is a danger it can be intercepted and the password can be used. Although to be fair this is not that much different than the risk of sending a password reset link.
If you ignore the risks in step #1 and you don't use a sufficiently random way of generating passwords (say you use a word list of fewer than 1000 items), someone who has hacked into your server will be able to retrieve the salted password hash and then write an algorithm that generates all possible passwords and checks them against the hashed password. Not as much of a problem if you use a cryptographically complex hashing algorithm.
If you want to send password to user via Email in cleartext and want to store those password into database as hash or any other format . It will be possible.......
Just you will have to follow some simple way....
1 .you will have to take those password as variable which will send from user.
2. When you store database then just convert it as you wishes format.
3. But when you send those to user by mail , That time just sent those variable password...
I think it will be helpful to build your concept about WAY.......
What would be the most secure method of using cookies to authenticate users in a classic ASP website?
I don't want to use the ASP Session object as the session cookie times out after a while, and I'd like the user to be able to keep their login to the website active between separate browser runnings.
However, I don't want to just create a cookie containing their user ID as that could be easily forged - so what are my options here? I guess some sort of encryption but I don't really know what the standard methods of doing this is.
Your options here are pretty much limited.
Get your users to log back in again; best security approach.
This obviously applies much wider than just ASP.
The best way would be to hash the password... you should be doing this in any case where you store it in database.
The hash is a cryptographic function - when you run a string through it (eg password) you get out a long code. If the input is the same, the output is always the same.
But (this is the important bit) its mathematically virtually impossible to reverse the process - to start with the hashed value and work out the password, other than brute force (someone hashes dictionary, or random strings and looks for output that matches the hash they have).
So when the user sets up account, they put in their desired password, but you hash this, and store that. Similarly in the cookie, after they login you store the hash, not the password, and this has is compared with the hash in the db.
The downside is you can't send a password reminder since you don't know the password - to you'd have to send a password reset link and have a system to do that.
If you're really paranoid you might double hash, eg when they login the password is hashed once and stored in cookie. Its then hashed again and compared with the password in db (which is also double-hashed).
Don't Do It
Maintaining a user login quote "...between separate browser runnings" is not secure. IMHO, when you close the browser a previous login should be gone. Suppose your visitor was using a community pc at a coffee shop.
If you maintain this login the potential for the next community user to open the browser, navigate to your website and "poof" they are automatically logged in as the previous user.
i have to create a login module (The question is not language specific) but i am not sure how will i validate the user. Where and how will i store the passwords. Will i have to encrypt and decrypt my passwords and if yes what are the best suggested way to do them. Overall i need to know what all things i need to take care of for developing a login module where a user can login securely to access my site.
You don't need to decrypt your passwords in order to validate them, just one way encryption works fine for this. The idea is that when a user enters a password, you encrypt it the same way (using the same algorithm and "salt") and then compare with the encrypted one stored in your database. If they are equal, with a great probability it means it's the same original password. Thus you prevent anyone - the adminstrator or any attacker - from knowing the original passwords users use on your web site.
As for the rest, it's very simple, you have a table in your database which contains user logins, encrypted passwords, and possibly some profile information as well (full name, etc).
I usually use the following function to hash user passwords:
$password_hash = sha1(MY_SALT_1 . $login_name . MY_SALT_2 .
$password . MY_SALT_3);
where MY_SALT_* are arbitrary predefined strings, could be e.g. 'the dark', 'side of', 'the moon' (or actually the less related - the better).
Yes.Sure you need to encrypt users passwords.Because most of the users using the same password almost all sites.At that time they are not want to show the passwords to admin.And another reason is most of the time the site DB may be accessed not only by admin.Some other technical persons in the organization.So it is better to encrypt the password.SHA1 is the best way to make the encryption.
Where and how will i store the passwords.
I am not sure what you mean by this.Every one use the database for it like phpmyadmin.
Is it any safer to create a table holding user information and another one for their passwords than using the same table for everything?
No I would just do this:
id, username, password.
Where id is just autoincrement, username is a varchar of 20 (or so, depending on your needs) and password is an MD5 or SHA1 hashed password with a salt.
Using two tables for this just doesn't make sense. Then you need to work with joins to get the data. And that's just an unnecessary burden.
No, I cannot see how that can make it safer.
You should actually refrain from storing passwords at all. Just store their salted hash.
Further reading:
Stack Overflow: Preferred Method of Storing Passwords In Database
I disagree with other people - put the authentication information in a separate table and to the greatest extent possible pull authentication out of your application entirely. You shouldn't care. Think siteminder and the like - your web application doesn't have any information about how the user is authenticated. Password, smart card, etc. (Same thing with Kerberos or Active Directory on desktop applications.)
This approach even works if you use a framework like Spring Security. Just set up your interceptor so it looks at the authentication tables alone. You could even use separate DataSources so your interceptor can't see application data or vice versa.
Obviously your application will still need to manage information about the user's authorizations, something usually handled in a 'roles' table. But there's no need to for it to know how the user was authenticated.
i think having the username and password in the same table is ok ,
but also l have seen people doing silly stuff especially when working with the ORM , someone might end up exposing password hashes etc
for example entity framework C#
someone can just do
appcontext.Users.ToList();
no attributes kept ensuring that password is hidden nor DTOs (Data Transfer Object) ,
upon noticing this l just keep another authentication table and the other thing l there are a lot of fields for forgot password, last password change all those fields l will have them in another table with the password
No it is not safer. Just make sure your passwords are Salted+Hashed before you stored them in the DB.
No. Not unless each table required a different user account to access it - which would make querying it a complete pain - and even then, the hacker has worked out one login, so chances are they can get the other.
Just make sure that you are storing passwords in a hashed form, using a secure hash like SHA-2 and a salt. Do not store them in plain text and (IMHO) don't store them encrypted.
Btw, there is already a pretty simple (and powerful) c# salted hash class library (they've also included a small demonstration of how to use the library) out there - Link .
It also provides a verification mechanism (so you can verify the user's input as a valid password) and you can choose the Hash algorithm yourself (Sha1/MD5/etc.)
There is no security benefit, but using multiple tables can be useful for storing credentials to multiple systems tied to a single login.
As mentioned above, security should be provided by salted hash for passwords.