I have a ticketing help desk and I want to edit my users' passwords. But the passwords are encrypted in database like this : $2a$08$IdljRhapMTPYzdB0l4t/AuHatF8imyNREH.yKtBZelmVJAi5Sa/c.
I want to change the password in my help desk user_edit.php file and enter password field like this: password#123 and the server automatically encrypt it.
That's quite an unsafe solution, you should instead think of updating password. If needed, first encrypt it and than compare to the elder one to know if the user haven't typed the same password, which is unsafe.
You will need to find and reuse the code of the system that has created those passwords, or encrypts user entry as part of login.
For security you should encrypt passwords "one way". For logins you take the plain text input of the password, encrypt that in the same way that the password was originally and compare the encrypted texts, to see whether they are the same.
Find and reuse this encryption to add a new password.to your user.
Related
We all know we shouldn't be storing user passwords as plain text on
the database. However I have seen some sites that have implemented
a send-forgotten-password feature. So if I ask my password, I type
my email and they send the password.
Note: I'm not talking about a password change (http://sample.com/forgot_pass?token=ddm39fhksnc)
How do these sites achieve it? They store plain passwords on their
databases (maybe a different database) because as far as I know you
can't reverse a password hash to the original string it was built from...
Is there anyway this feature can be implemented securely? Or I should
convince clients to stick with forgot-pass-link method.
Thanks.
If they are able to send you your password then they are storing your password in plain text.
Note that you can find out the original password from the hash if a deprecated hash function was used (like md5).
There is no way of doing it securely. If your database gets breached the attacker will be able to read out all the passwords and corresponding email addresses/usernames. If your users re-use the same password for different sites (which most people do) what can happen.
Even if there would be a "secure" way of finding out the password from its hash, what stops the attacker from doing the same?
Such a feature cannot be implemented securely. If the application can retrieve the original password (e.g. from an encrypted password), a successful attacker can retrieve the passwords as well. That's why one should use a hash function like BCrypt, SCrypt or PBKDF2.
Another weakness is sending the password at all per e-mail. A better way is to send a token, and let the user choose his own password after confirmation. The same code can be used to register a new user and to reset a password.
You open the door to major security issues if you store the actual password in the database. But if in fact you must resend their password to them, one way you could do it, is when they register, store the password in a text file located outside of the public directory.
Then create some sort of naming logic that associates the record to the text file. And then from there, make it so the only way you can access that text file is with the proper security checks in place, and then via your script.
My solution is adding two field in table "user" in my database: "token" field and "expired_time" field.
When user send a request to reset password, your application will update token string and expired time to reset password for that user.
Send an email with link has username (or email, or id,...) and token like http://example.com/resetpassword.php?id=userid&token=token
In resetpassword.php, you will check authentication by userid, token and in expired time (maybe 5 minutes)
Allow user to change their password.
This is my solution, I hope it'll helpful :)
Maybe silly question...,
but i'm asking myself if it's useful to store the password (plain text) in the database once i have hashed it using password_hash() function...
Since password_verify() only uses hashnSalt to check if pass is correct.
once the "Villain" obtain access to the db he doesn't have plain text password (will ask him time to bruteforce them)
If the user forget his password he can't get it back : only way is to recreate a new pass.
i'm on a 50/50..
Do NOT EVER under any circumstances store plaintext passwords. Doing this defeats the entire purpose of hashing the password in the first place.
The entire purpose of using a one way hasing algorithm is that if a hacker gets into your site and steals your database it is virtually impossible for that hacker to obtain the passwords for your users without using bruteforce or tables. (The tables risk is also mitigated by the salt introduced by the password_hash() function.)
You should never be able to retrieve your users' passwords, even as the site owner/operator (if you can, then a hacker can too). That's why any website that will send you your password instead of having you reset it is a red flag immediately as they are not storing your credentials securely.
The correct way to handle this is if a user forgets their password you send a temporary link which allows the user to create a new password.
First: never store plain text passwords! Probably the user uses more than one place the same password, and you would give the login information to other services for the attacker.
I would sabe only the created hash and if the user needs to remember the password he/she would have to reset it with a new one. The method to do this you can choose, but sending an email with a unique temporary link the best solution.
if a user forget his password, you can send him/her email with a link to his page and ask him to change his password. or you can set a new password for the user and send it to that user
I need an old password (not hashed) for sending to user but doesn't see a good idea? I read the documentation and there is only a method where I can get a hashed password. What can I do for getting real password?
Password should never be recovered clean after they are hashed and most of the time it's not even possible. I definitely suggest you to provide a reset password link instead of providing the old one.
Hashed password with MD5, SHA1, SHA2, Blowfish and others are one way encrypted this means that you shouldn't be able to decrypt them therefore making them secure (the first ones aren't that secure actually, but that's off topic here).
You can't get the original password; that is the point of using a hash.
If the user needs a new password, then generate a one-time, short-lived, random string and email it to them as part of a URL. When they follow the link, prompt them for a new password.
See the OWASP Forgot Password Cheat Sheet for more advice on how to do this as securely as possible.
You can't recover old password (unhashed) because its not stored in database. Only its hash is stored. Hashed can't be decrypted (that is why its called hash) ORM uses this model to solve alot of security issues.
Sending raw Password is real BAD idea. If you still want to do it:
If you are generating a password yourself during registration (Then mail it to user and then save it)
If user are setting their password. You will have it as POST variable. While saving it to database, mail it too.
If user is using forgot password to recover their password. Then reset the password first (generate a new one and save it to database) and send it to user.
You can't. A hashed password in Kohana is most likely a password encrypted with one-way encryption. I mean you can't decrypt it and get it in clear text. You should not store your applications password in clear text to protect the user.
http://en.wikipedia.org/wiki/Cryptographic_hash_function
What you may do is to generate a new temporary password for the user and send it to the users email, but I think reset password link is the best solution.
I am training to secure the login process.
I have used sha 256 in the sign_up.php:
$username= check_input($_POST['username']);
$password= check_input($_POST['password']);
//the password is encrypted in sha256
$secure_sign_up_password = hash('sha256', $password);
and then of course in my users table in my SQL database, I can read:
in the column 'login' the actual typed login
example: if somebody type 'michael', I will see 'Michael' in the SQL database
in the column 'password' the actual typed login
example: if somebody type 'fruit', I will see the hashed value like 'e8bfab56c53980cd014206c8da2f8c9b9708eaacc61' in the SQL database
My question is simple but maybe a bit naive (I'm a newbie): I thought that I could still be able to read the actual password somewhere in my database and that hashing was only made to protect the password from getting intercepted and read while it was being sent. I never know, somebody might ask me to send him his real password. But the only thing I can see is the 'hashed' one in the password column.
Is it made to be like this?
Is it possible to visualize also the real password?
If you would be able to "decode" those passwords, it wouldn't be a very safe system. Once someone gained access to your database - they would be able to gain access to every ones passwords without them knowing...
If you have ever forgotten a password for a site (and we all have - don't deny it!), you'll recall that they usually* don't simply send you your password (in plain text) as a reminder to your email - they'll give you the opportunity to reset it. This way (verifying usually through your email/phone number) they'll know that you are indeed the person who opened the account.
* If they send you your password in plain text that probably means they are storing it like that or in some other easily decrypted form. This site is most likely not as secure as they would like to think...
If you are interested in leaving yourself a "backdoor" of sorts to be able to access any of your users accounts, what you might think of doing is having a special login form from inside your administrator account, that allows you to use the encoded password to log in. That means that you simply leave out the hash('sha256', $password) and pass the $password already encoded (which you extract from your database). It's a bit hacky, and if you already have an administrator account then there wouldn't be much use to be able to log in as a different user because you are already all powerful!
This is by design. Nobody should know what my password is, except for me. Even you as a (insert fancy title here) should not know my password. If I forget it, that's my problem, but your site should offer me a way to reset it. Then when I reset, your site should store the hash once again. The plain-text password should never be stored anywhere.
Never never never hold password in open format in database. If someone find exploit in system, he will be able to make any sql query and get users passwords. And hacker will be able to login into system as user, because he knows username and password
If user want restore password, make functionality for regenerating password. Never store password in plain text.
SHA256 is hash function. Mathematically it means - data can be "hashed" only in one way. I mean, that from hash you cannot restore data. You can read this http://en.wikipedia.org/wiki/Hash_function about hash functions and this about http://en.wikipedia.org/wiki/Sha256 sha256
Result: If someone crack you database and get username and password, he is unable to login into system. Because hacker have only hash data and can't get exactly password for login.
As i mentioned before, hash function can be "hash" data only in one way. But some hackers build VERY big data massive for some predefined algorithms. I mean, that they build hash tables for passwords. Such hash tables looks something like this:
password hash
------------------
a some_hash1
b some_hash2
... .....
qwerty some_hash3
some_data some_hash3 -- yes, data can have collisions. See wiki about hash functions
And if hacker hacked you database and have such table, he able to restore password. For example, hacker get for admin user hash "some_hash3", then hacker search such hash in hash table, find that hash "some_hash3" have password "qwerty" and "some_data" and hacker will try to login with such passwords.
Result: Use salt. For nowadays hackers have such tables for 6 symbols passwords. But you can "suck" them in very simple technic: When you store password in database, add to password some value (salt) and get from such value hash:
// somewhere in code, where creating/updating users password
$password = hash('sha256', $salt.$password);
and when you will check password, use the same logic
Thanks
sha256 hashes and other hashes are one way. See http://en.wikipedia.org/wiki/Cryptographic_hash_function. If you want to be able to decrypt what you write in the password fields in your database, you might want to use another approach.
Instead of creating a hash, you could encrypt with a key, that you do not share with your users. Look at http://www.php.net/manual/en/book.mcrypt.php. The key would be part of your code though, as it's symmetric encryption.
To do it really safe, try real PKI encryption (encrypt with a public key, decrypt with a private one). Look at php.net/manual/en/function.gnupg-encrypt.php or php.net/manual/en/book.openssl.php.
But as other here have said, such things are reasonably NOT done ;)
So I am making a basic log-in page. I have a good idea of what to do, but I'm still unsure of some things.
I have a database full of students and a password column of course. I know I'm going to use md5 encryption in that column. The student enters their e-mail and student ID, and they get e-mailed a password if correct.
But, where do I create the password? Do I have to manually add the password (which is just a randomly generated string) in mySQL to all the students? And I am suppose to send the password to the student; how will I know what to send the student if the password is encrypted?
I was thinking about generating the password when the student first enters their e-mail and student ID. They get an e-mail of the random string, and at the same time, I add the same random string to the database, encrypted.
Is that how it's suppose to work though? And it feels unsafe doing that all on the same page.
Sorry for the long-winded, newbish question. I find this all facisnating at the same time as well (AES and RSA encryption :O)
A few things here:
You aren't really encrypting it, you're hashing it. Easy thing for newbies to confuse, but just wanted to get that out of the way.
Don't use MD5, it's just not a very secure hash. Use one of the SHA variants instead if possible.
Don't just hash the password, you'll want to "salt" it too. Basicly this involves adding a random string to the password before you hash it, and storing that random string somewhere where you can retrieve it later (so that you can validate the hash when the user enters their password). This helps prevent against pre-computed dictionary attacks.
As for generating the password, I think you are on the right track - I would just generate it when they create their account, email it to them, then hash it and store the hashed (and a random salt) on the user record in the DB.
If you're generating passwords, generate a password and send the generated password to the student. MD5 that password and store it in the database. When someone logs in, MD5 the password they submitted in the form and compare that hash to the one in the database. If they match, successful login.
Your PHP should generate the password at the time of registration. Email the password to the student then run it through a hashing function (md5() is ok but sha1() is better). Store the hash in the DB and drop the original password. That way not even you can see what it is.
When the user logs in, hash their typed password and compare it against the hash stored in the DB. If they match, the user typed the right password.
Adding to the previous answers, depending on the hashing method you choose, the process goes like this:
1.- It is good idea generating the password the first time the students enter their ID and email.
2.- When they submit their data you receive it and generate the password randomly using any hashing method of your choice and store it in your DB.
3.- When they want to log in you ask for their ID and password, use the hashing method on the entered password and compare it with the one that's stored.
4.- If they lose their password and the hashing method has no way to be undone or reversed, you need to implement a method to create a temporary link sent to the student's email to create a new password, for there's no way to retrieve the old one. If the hashing method can be reversed then there's no problem, just de-hash it and send it to the studen's email.
Hope this clarifies a bit the process :)