This question is based on the answer.
I would like to know how you can hash your password by SHA1 and then remove the clear-text password in a MySQL database by Python.
How can you hash your password in a MySQL database by Python?
As the documentation says you should use hashlib library not the sha since python 2.5.
It is pretty easy to do make a hash.
hexhash = hashlib.sha512("some text").hexdigest()
This hex number will be easy to store in a database.
If you're storing passwords in a database, a recommended article to read is Jeff's You're Probably Storing Passwords Incorrectly. This article describes the use of salt and some of the things about storing passwords that are deceptively easy to get wrong.
http://docs.python.org/library/sha.html
The python documentation explains this a lot better than I can.
You don't remove the clear-text password when you hash the password. What you do is accept an input from the user, hash the input, and compare the hash of the input to the hash stored in the database. You should never store or send the plain-text password that the user has.
That said, you can use the sha library as scrager said (pre-Python 2.5) and the hashlib library as David Raznick said in newer versions of Python.
Related
I need user_password plaintext using Django. I tried many ways to get plaintext in user_password. but It's not working. So, I analyzed how the Django user password is generated. it's using the make_password method in the Django core model. In this method generating the hashed code using( pbkdf2_sha256) algorthm. If any possible to decrypt the password.
Example:
pbkdf2_sha256$150000$O9hNDLwzBc7r$RzJPG76Vki36xEflUPKn37jYI3xRbbf6MTPrWbjFrgQ=
As you have already seen, Django uses hashing method like SHA256 in this case. Hashing mechanisms basically use lossy compression method, so there is no way to decrypt hashed messages as they are irreversible. Because it is not encryption and there is no backward method like decryption. It is safe to store password in the hashed form, as only creator of the password should know the original password and the backend system just compares the hashes.
This is normal situation for most backend frameworks. Because this is made for security reasons so far. Passwords are hashed and saved in the database so that even if the malicious user gets access to the database, he can't find usefull information there or it will be really hard to crack the hashes with some huge words dictionary.
I'm working on a python script that will need to connect to a postgreSQL server. What the best practice for the username and password? In this tutorial ZetCode is just using the username and password (if needed) in the code itself. Is this the right way or should there be some sort of hashed file to read from?
http://zetcode.com/db/postgresqlpythontutorial/
Store the username and password in a file, then restricting access to that file would be a good start.
Storing a hashed username or password won't work, because you cannot undo a hash function.
If you think that storing the username and password in plain text isn't secure enough in your situation, encrypt them. When the script starts, it asks for the passphrase. That passphrase is then hashed using PBKDF2 or scrypt. Use that hash as the key for encryption/decryption. See cryptographic right answers.
This does mean that your script needs operator input every time it starts!
I'm making a company back-end that should include a password-safe type feature. Obviously the passwords needs to be plain text so the users can read them, or at least "reversible" to plain text somehow, so I can't use hashes.
Is there anything more secure I can do than just placing the passwords in plain-text into the database?
Note: These are (mostly) auto-generated passwords that is never re-used for anything except the purpose they are saved for, which is mostly FTP server credentials.
You can use MySQL's ENCODE(), DES_ENCRYPT() or AES_ENCRYPT() functions, and store the keys used to encrypt in a secure location.
Use encryption. The passwords won't be in plain text so you'll have some security but it can be reversed.
The code in this answer should do the trick.
I've been asked to encrypt various db fields within the db.
Problem is that these fields need be decrypted after being read.
I'm using Django and SQL Server 2005.
Any good ideas?
See: Using Symmetric Encryption in a SQL Server 2005 Database
Yeah. Tell whoever told you to get real. Makes no / little sense. If it is about the stored values - enterprise edition 2008 can store encrypted DB files.
Otherwise, if you really need to (with all disadvantages) just encrypt them and store them as byte fields.
I had the same problem, and created the following solution: http://djangosnippets.org/snippets/2489/
I happened to use M2Crypto as the cipher engine, but that can be swapped out if desired.
As TomTom notes, doing this just raises the bar for an attacker rather than making hostile decryption impossible - in addition to accessing your database, they now also need to access wherever you store the passphrase that feeds into the key derivation function. However, by splitting the key from the data it is protecting in this way, you at least now have the option to further secure that key (e.g. with a key management server) to raise the bar yet higher. Defence in depth is a good strategy, but you also need to decide what constitutues overkill for a given application.
It's also a terrible idea to encrypt any field that might be useful for searching or sorting purposes (I only use this trick to store OAuth credentials for a web service that doesn't support proper tokenised OAuth connections).
If you are storing things like passwords, you can do this:
store users' passwords as their SHA256 hashes
get the user's password
hash it
List item
check it against the stored password
You can create a SHA-256 hash in Python by using the hashlib module.
Hope this helps
I am making a simple web-app which requires login for the admin page. I came across this incantation on the web.py site (http://webpy.org/cookbook/userauth) :
import hashlib
import web
def POST(self):
i = web.input()
authdb = sqlite3.connect('users.db')
pwdhash = hashlib.md5(i.password).hexdigest()
check = authdb.execute('select * from users where username=? and password=?', (i.username, pwdhash))
if check:
session.loggedin = True
session.username = i.username
raise web.seeother('/results')
else: return render.base("Those login details don't work.")
However the page also gives a somewhat ominous warning: "Do not use this code on real site - this is only for illustration.". I was wondering if there are any major holes in this, I'm somewhat unfamiliar with web-programming so just wanted to make sure that using this code wont unwittingly make the app open to trivial attack vectors?
Many thanks
select * from users where username=? and password=?', (i.username, pwdhash)
^ SQL injection, broseph. If someone does 'or 1=1' into the search field, they'll get the first result in users because of the SELECT * from. Often the first entry is the admin credentials.
The only glaringly obvious problem I see is that the password is stored with as simple MD5 hash with no salt. From your point of view, this isn't so much of an issue, but from the user's point of view it's a major security flaw since someone with access to the database can fairly easily crack sufficiently bad passwords by just googling their MD5 hashes.
The only possible problem I can think of here, could be if it would somehow be possible to exploit MD5 collisions, i.e. that two different strings can generate the same MD5 hash - in that case someone could potentially log in with a password that is not correct, but generates the same MD5 hash.
Changing to a better hashing algorithm such as SHA-1 (or something else available in hashlib) would close this potential security problem.
As far as I know, it would be very difficult to exploit the MD5 collision problem to gain access. Even so, it is broken, and quoting security guru Bruce Schneier from the wikipedia article:
[he] wrote of the attack that "[w]e already knew that MD5 is a broken hash function" and that "no one should be using MD5 anymore."