We currently have a login process that uses a secret salt (pepper) that's hard-coded and appends that to the plaintext password to create a hash that gets stored in the database.
I just updated the process so that it also uses a random salt for each user and stores that along with the final hash in the database. I have that logic working correctly, but ideally I also want to update all of the existing stored user login data in the database without requiring the users to reset their passwords.
Is there a way to update a hash with a new salt if I know the old salt but not the plaintext password? I know I could theoretically just brute force to get the old passwords because I know the salt, but I was hoping there was a more sophisticated way to pull this off.
Related
I'm using Django (version 2.0) as a newbie and have forgotten the admin superuser password. I know that I can create another superuser and change the password of the previous superuser as well. But is there any procedure to know the RAW password of the previous superuser which I've forgotten?
By default, passwords are not stored in raw text in the Database, but hashed. It means that, given the hashing algorithm is a good one, and the gap theorem holds, except for enumerating all possible passwords, there is not much you can do to find out the password. A lot of hashing algorithms have some weaknesses, but typically this helps not much: it makes guessing for example sometimes 10 or 100 times faster, but still, it would take ages before you guess the correct one.
Hashing means that we thus have a function h which is considered to be a good hashing function, that transforms the password in some data, and that data is stored in the database. The same password should result in the same hashed data, and usually a small change in the in the input (password) results in a large change of the output (the data we store). A good hashing function has the property that it is not feasible to calculate the inverse: this means that there should not be straightforward way to calculate the input (password) based on the output (stored data), except by enumerating all possible input until the output of such "guess" eventually matches the hash. In case a user logs in, Django will first calculate the hash of the given password, and then check if it matches with the stored hash. If so, the login is successful, if not, the login fails.
An implication is that a (malicious) database manager can not see the passwords as well. Imagine that you use the same password for all your applications (not recommended anyway), if one of the servers stores the passwords as raw text, somebody with access to the database (a hacker, or a company employee) could see the passwords, and thus aim to use these credentials for other services (for example an email service). By hashing, the damage is typically more local (perhaps the hacker can steal user data, but not reuse the credentials to discover more data somewhere else).
Nevertheless, if you have access to the Django admin shell, you can simply change the password to a given one. Since Django has access to the database (well given you have provided the database password somewhere), it can simply overwrite the password field with a hashed version of the new password. Regardless what the old password is, thenn the new password will work.
You can do this by running:
python3 manage.py changepassword <username>
With <username> the name of the admin user.
It's impossible to get passwords of a user in any Django app, by design.
I'm implementing a change password feature for my Django app, and one of the requirements is to ensure users don't keep a new password that's the same as their previous one.
I can't do string comparison here, so what's the optimal pattern to follow in this case?
Here's what I'm thinking: accessing my change password feature requires re-auth (i.e. users have to input the pass again). I can conceivably save the password string in a session variable at this point (e.g. session.request['old_password']), and then compare this session variable with the string of the new password the user sets? Any security concerns with this kind of a pattern?
You don't need to store the old password in a session and you shouldn't either. Because the session data get's saved in the session storage and for that brief period when the password is being changed, it's there in plain text format. Theoretically an attacker could use a database event or trigger to capture these plain text password objects. The better approach would be to use django's built in password functions.
check_password(password, encoded) If you’d like to manually
authenticate a user by comparing a plain-text password to the hashed
password in the database, use the convenience function
check_password(). It takes two arguments: the plain-text password to
check, and the full value of a user’s password field in the database
to check against, and returns True if they match, False otherwise.
In your case you would need to create a custom form, that calls this method as part of it's clean() method. If the above function call returns true, you need to raise a validation error saying the old password is being reused.
Following on from my suggestion under e4c5's answer, it would appear as though there are existing packages such as Django Password Validator that will do this for you so you don't really need to write it yourself.
Essentially, it seems that this works via storing the previously used hashed passwords in a database and then comparing the new hashed password to those currently stored.
See the source code for their validator for more information.
I'm working on a desktop application which has a login system. It's written in C++. When it's started, asks for a username and a password then connects to the MySQL database and verifies the entered data. Currently the server's password is hardcoded to application's executable. I know that this is a bad practice, so I would ask your opinion about solving this issue. I should store the server's password encrypted then decrypt every time when a database connection is required, or there is a clever way to do it?
Clarification:
I have a MySQL database with user "root" and password "root". I create a connection to database with that username and password. But when the user wants to log in he enters his username and password which has nothing to do with the root username of the database. That username and password is stored in a table created by me.
Essentially there is no foolproof way to do it, a determined user could find a way to find out the password. There are ways to try and make it harder e.g. obfuscation, etc. which you can see in this similar question.
You can use md5 for encrypting the password. It is one way encryption. If you want to check if the password is correct, create the md5 value of the entred string and then compare it with the string stored in the database. So the actual password won't be visible. You can refer the link http://www.zedwood.com/article/cpp-md5-function
If you're application is on Windows there is a Credential Manager you can use (and possibly something similar for Linux):
https://stackoverflow.com/a/9228105/222748
Another approach is to use encrypted XML that involves the use of a self-signed certificate for asymmetric encryption. Here's how it works:
https://www.ibm.com/support/knowledgecenter/en/SS7JFU_8.5.5/com.ibm.websphere.express.doc/ae/cwbs_encryptv6.html
For generating the MySql password for the database I'd look at using a Crypto library as this is less easy to predict than random functions based on time.
I'm a pretty newbie in Django framework. While just walking around the django's default authentication system, I found that django stores user's password in algorithm$salt$hashed format. And the salt is not same for every single user; django generates every new salt for each user.
I've made several web pages and got many chances using other open source softwares, but there was always only 'one' salt string for hashing.
So, my question is:
Why django uses 'random' salt beside 'one' salt string?
Why django stores it in same column with password hash?
Why django uses 'random' salt beside 'one' salt string?
Because if you would have one salt you could generate rainbow tables for your database easier than when there are random salts.
If you would like to generate rainbow tables to decrypt django hashes you would have to generate tables for each different salt in database. Generating of rainbow tables take very long time, it's just brute force or dictionary attack.
Why django stores it in same column with password hash?
I don't know what are you specifically asking about but there are probably 2 answers.
-It's stored because someone designed it that way. It could be on salt field and it wouldn't matter.
-When user send password via form django join salt to string and than calculate sha1 and check if it match the one in db.
The random salt prevents using a rainbow table to quickly decrypt all passwords in the table. Instead they have to do each one separately.
The practice of salting a password is intended to make it more difficult for an attacker to brute-force crack the passwords you've stored. More info.
I have a website (the basic gist of which is described in this question), and I want to have some way to store the username and some information about the user consistently while they use the site (ie, upload and download data).
Right now, given a successful login, I was returning the hash of the password as well as any associated information. Anytime a user tries something, their username, hash, and so forth must match what's in the database. If the user logs out, their local Sinatra session has all information flushed.
I realize that this is a very naive approach. Is there a better way to handle user session information? The wikipedia entry on cookies mentions that a session uid is used instead of this other information; what is the advantage of that approach? I suspect that this approach is also vulnerable to other attacks, but since I verify everything that's done as it's done, I'm not sure what attacks I'm leaving myself open to.
Also, if/when I implement ssl, will these transactions be 'automagically' encrypted, or will I need to do something else to make sure that the strings are protected, if they need to be?
This is actually a very complicated issue. Just to illustrate, you have the problem of account lock-out: If you lock out based on failed attempts, how easy is it for an attacker to DOS your website?
I'll list a few best-practices to get you started:
Store Passwords Salted and Hashed alongside the Username and UserId. (You should also store the salt next to the hash.)
Disallow frequent bad-password attempts. (More frequent than once every few seconds).
If attempts are failing for any given user or any given IP address (more than 3 times a minute) require some form of human-validation, like a CAPTCHA. This allows you to prevent total DOS attacks.
If implementing an auto-login system, use a token authentication system.
For token authentication systems, use a Secure random number generator, send the plain token to the users, but Salt and Hash the token at the database.
Use TLS/SSL if possible, but don't rely on their security once the data is off-the-wire.
If your website is built in asp.net then you can use dot net securities.. which is really very good. and you can also use principle classes in it to make it more secure..