How do we retrieve a password of an user?
u = User.objects.get(username__exact=username)
print u.password
displays sha1$f0971$441cac8f604d49869e33ca125a76253a02fef64e
Is there a function to find the password from this encoded string?
No. It's impossible, by design. But there should never be a need to do it anyway.
Due to security restrictions the password hash method is one way. You will need to reset that users password.
Try using the set_password(raw_password) method to give the user a new password. Remember to call the save() method to ensure you save the change to the database.
u = User.objects.get(username__exact=username)
u.set_password(raw_password)
u.save()
You can check if the password is correct with:
u.check_password("your password")
This method and u.set_password("you password") solves all of your problems.
sha1$f0971$441cac8f604d49869e33ca125a76253a02fef64e is:
hash function algorithm $ salt $ hash code
no. and there shouldn't be. as part of the security, passwords are passed through a one-way function before they are saved, so that they aren't reveled if the database is compromised
what you can do is replace the user's password with one you know. this is how (good) site's "forgot your password" functions work: they send you a new random password, not your old one, since they (shouldn't) have access to it
No, the field contains the salted hash of the password. from the string we know it's SHA1 function. If you have the password, you will be able to produce the same hash value which acts as the footprint. For security reason there should be now way to recover the password in a economical means (you can still brute force, but will take long time).,
There is no way you can get the existing password because that password is been converted to salt hash.
Related
I'm trying to make a desktop C++ application (using Qt, if it matters for this problem) that features an authentication system. It can be used by ONE user at a time. When the application starts, a log in form will allow the user to type his username and password. After logging in, a new window will be displayed. My question is: should I pass the user's ID and/or username to the next window [as a constructor parameter?] (and use such system for other windows as well) OR would it be ok (I'd much rather prefer this) to store this data in the static fields of a class and access it from everywhere? [doesn't sound too bad since I only allow ONE user to be logged in at any time]. I should also mention that I'll be trying to use the Model-View-Controller pattern.
Do you need to store it? I mean, once user clicks "Login" on your login dialog, it checks whether entered name/password combination is authorized to use the app and than the rest of the app starts, knowing user is authorized and without any other checks/using of credentials.
In case you do need to store username (for example you display somewhere in header that user is logged in as XXX or you use it for some other reason) I would recommend to save it statically somewhere. The other way (passing it all over the place) means that you would have to store copies userID/name all over the rest of your app.
Also, if you have more user-releated information (like selected theme, some configs, user specific file paths or something) keep it in one place (create struct/object with all this in it)
Pro tip #1:
Do not store password in that struct. Once you check whether user is authorized or not dump it. And by that I mean don't just stop using it/forget pointer but overwrite all places in memory where the password was stored to prevent some RAM reading attacks.
// Example
char *password = getPasswordFromLoginDialog();
// Do some stuff (check it)
while (*password) { // while we are not at the end of 0 terminated string
*password = 0; // zero it
password ++; // move on
}
Pro tip #2:
Usual way to compare 2 strings is to go char by char and once they are not the same tell that 2 strings differ and thus password is not accepted. However, it takes marginally longer time to find char missmatch at say 7th position than at 1st. Attacker can exploit that using brute-force and statistics and work out password one char by one.
Easy way to defeat this: After user tries to login wait random period of time and after that start checking if the password is correct or not. This way it will disrupt this time based brute-force attack
More proper way how to check whether password is correct or not: Don't check actual password, but hash it first using some crypto-secure hash like SHA256 and then compare hashes. Preferably hash the hash and hash the hash of hash and so on, about 1000 times, so it takes much longer to bruteforce if attacker gets raw hash of password.
Pro tip #3:
Never ever hardcode usernames/passwords into your application. It is pretty easy to decompile and pull these pairs from it. I don't know exactly what you are working on, but I would suggest querying 1000 times hashed hashes of password from some SQL database or something like that. If you have to use hardcoded passwords, dont use raw string, but those hashes
Pro tip #4:
Use salt (Salt - wiki). That is pretty much some random data you put before/after password before you hash it. For additional security it is better to assign each user different salt.
Reason for salts is that same passwords have same hashes. When you have lookup table of common passwords and hashes, you can de-hash password very easily. Not using different salt for each user (or not using it at all) has some consequences: when there is a leak of password(hashes) database attacker instantly knows which users have same password
Pro tip #5:
If you are using some sort of client-server authorization system, make sure you salt-hash password client side (before sending it over network) and also on server side (before storing to db/comparing against db). This way when there is a leak of db attacker can't use those stored hashes to authorize himself, because they get hashed (once) more on server side before actual authorization process.
Keep in mind, that if attacker intercepts salt-hashed password when client is sending it to server he CAN use it to authorize himself. However, when using network, you should encapsulate all your traffic in some sort of encrypted tunnel (have a look at TLS)
Hope this helps
Have a local copy of Wiki (MediaWiki) but my predecessor left without handing over the password.
I got access to the server panel, and to mySQL, but despite I try to change the password as explained at https://www.mediawiki.org/wiki/Manual:Resetting_passwords I can't get it working.
In the localSetting.php file there is not a salt specified, which from ver 1.13 onward seems to be deprecated, but somehow my password have one.
E.g. :B:d1c1ee33:115272fdacb0ff5f6dcb3639d0bc08b3
Looking at the ./includes/User.php file, there is a crypt function that generate a random salt, so technically as long as I use a random name while using the following update statement I should be fine.
UPDATE `user` SET user_password = CONCAT(':B:somesalt:', MD5(CONCAT('somesalt-', MD5('somepass')))) WHERE user_name = 'someuser';
That's not the case. Anybody can help?
Use a maintenance script such as changePassword.php or createAndPromote.php.
I'm using this snippet, that allows users to only need to enter an email address to register for my app: http://djangosnippets.org/snippets/686/
Things are almost working perfectly. The problem is when a user has an email address that's above 30 characters. I get a "Ensure this value has at most 30 characters (it has 40)." error.
This is because the username is only supposed to be 30 characters. Is there a simple way to just tell Django that the username can be longer? It seems like there should be a fairly straightforward override for this.
This actually isn't simple at all. This requires subclassing the User model and using that everywhere. I've never had to do it, for this case, but it would likely cause significant issues with the Admin interface. You could also edit django's source to pull it off (ick).
Or even use this solution:
Can django's auth_user.username be varchar(75)? How could that be done?
It's quite ugly though.
You're probably better off writing an authentication backend to use the email field for authentication rather than using the username field. To populate the username (which is required) then you'd just generate some sort of random unique username maybe by hashing or using a UUID.
Hopefully this solution should help you : http://www.micahcarrick.com/django-email-authentication.html
I am writing an application that needs to read a user name and password and store them so that the program can read them again later. Storing it in some variables sounds like a stupid idea.
Found that KDE library, but it has too huge dependency, and I am too newbie programmer to understand how to use it.
What are the common Methods to storing passwords, and how I can solve my problem?
It depends on what you are going to do with the information.
If you are going to use the name and password to access some external service (but the user will have to reenter the information the next time the program is run), then storing them in some variables is OK. It might be wise to store them encrypted (at least, store the password encrypted) so that it is not visible in core dumps or the equivalent. When the password is needed, you decrypt it, use it, and then write over where the decrypted version was stored (zapping it). (Note: hashing is not appropriate in this context; you need to be able to see the password, and you can't undo a hash.) You could decide to store the information outside the program (in a disk file), but it doesn't seem necessary. Note that the binary will still contain the encryption key (and encryption algorithm), and encrypted data is more random than the average contents of your program, so to really conceal the encrypted password is actually very difficult (verging on impossible). However, you can make it hard enough that it will stop all but the most determined attackers.
If you are going to store the username and password as a permanent record so that you can validate that the same user is accessing the information in the future, then you must use storage external to the program; you will use a simple database, which might be as simple as a plain text file if you ensure you resolve any concurrency issues. In this case, you will hash the password with some salt, and you'll store the username, salt and hashed password in such a way that given the username, you can easily find the other two values.
Night Walker comments:
I use that password to access some web database, so I need it stored in my application after it is entered for the first time. Are you sure a plain text file is that smart an idea?
It depends on how you conceive 'stored in my application'. You can't modify the executable, or at least shouldn't try to do so. So, you need to look on it as a permanent record stored in some sort of file separate from the application executable. On the other hand, you do face a different problem from what I outlined - you are not authenticating the user with the information; you need to decrypt the information on demand to send on to other applications.
First off, that means that salts and hashes are not relevant; you need to reverse the masking operation, and you can't reverse a hash.
Next, you need to decide how you will identify the user of your application upon reappearance. Will the user be obliged to enter some password to get to their own data, or will you simply rely on the operating system privileges, or some other scheme.
If the user must enter some password into your application to get going, then you can consider using that password (or a hash of it, distinct from the password hash used to recognize the password to the application) to encrypt the username/password combination for the external application. You can then store the username and, for sake of argument, a Base-64 encoded version of the encrypted password into a text file; this is as safe as the application password, which is stored in the original salted hash format. When the user returns, they have to supply their application username and password, and you can validate that combination against the stored values, and then use the password to decrypt the password to the external application.
If the user does not enter a password, then you are more restricted in what you can do. You have to be able to determine a key somehow from the information available to you that can be used to store the user's encrypted password in a file in a restricted location such as a sub-directory underneath their home directory with no group or public access:
mkdir ~/.appname
chmod 700 ~/.appname
cp /dev/null ~/.appname/app.key
...store the encrypted information...
chmod 500 ~/.appname
chmod 400 ~/.appname/app.key
This is less satisfactory because even if you combine a fixed key with the user's name, say, the chances are that someone can work out what that key is (and the encryption technology) and reverse engineer it. (The secrecy of encrypted data depends on the keys; when the key is determinable by the program, it is also determinable by a determined attacker. It is best, by far, to rely on the user to provide the key (or a password or pass phrase) at run-time; then the application does not store anything that an attacker can use offline.
Usually you store the username and a hashed version of the password. See this wikipedia article: hash functions, and this question.
Common method to store passwords for later use is to store them in some encrypted cache. That cache is encrypted using some master password. User should enter master password each time you need password from cache. KeePassX is a small open source application that uses master password to store personal data (user names, passwords, etc.) It has a light interface, is cross platform and published under the terms of the GNU General Public License. You could check it as sample and use some parts of it.
What about MySQL or SQLite? Hash the password and store them in a persistent database, no?
I would suggest storing a hashed password in SQLite. Then whenever you need to check a password, hash it and then compare it against the stored value. This keeps the stored passwords secure so no one (not even you) know what they are.
what kind of application is it? There are many methods but if its ASP.Net it's common to encrypt in the web.config file.
At spotep.com we only store the username and a hashcode of the username combined with the password. The benefit of this is that similair (often trivial) passwords wont result in the same hashcode (which is stored in a cookie, and therefore very unsafe).
You could try QSettings which provides persistent platform-independent application settings. Solutions like mysql would be overkill unless you have hundreds of passwords to store.
from django.contrib.auth.models import User
u = User.objects.get(username='test')
user.password
u'sha1$c6755$66fc32b05c2be8acc9f75eac3d87d3a88f513802
Is reversing this password encryption possible?
Yes, it's possible. All you need is a few million years, and a computer the size of our solar system.
Sha-1 is a one-way hash. It cannot be reversed except for using a brute force attack which will take millions of years.
There are some online databases that let you reverse the hash of common words/conbinations of words. However, django adds "salt" to the password before it computes the hash, so you cannot reverse django passwords.
That's why a hash is used. Nobody can find out your password, not even sys admins :-)
No, that's the point.
If your user forgot their password, you'll have to reset it.
Django is using sha1 which is a one way hash for password hashing and "salt" the password before encrypting them. So it will take much longer time (maybe our lifetime) to decrypt them. The passwords are hashed so that no one will be able to decrypt it even if they have the hashed values.