I am creating a login system for my own website so I can update it via a form. I have manually added myself to a table in the database I called users, although there will only ever be me, and I added my password plain text. However, I have since being reading about hashing passwords, but from what I can see this is only done from a php function, can I do it in phpMyAdmin using just the sql section?
If you edit the structure of your table, there should be a column called "Function".
There you can select MD5, and any value stored in that Field will become hashed. So if you already have a password stored in your table, it will become hashed aswell.
Like this: http://www.xodino.it/wp-content/uploads/file/ubuntuftp/pureftpd-02.png
Have a look here:
http://dev.mysql.com/doc/refman/5.1/en/password-hashing.html
But if you want to do it with PHP take a look here. That's a good article about password hashing:
http://phpsec.org/articles/2005/password-hashing.html
You should salt your password and then hash it. Passwords that use MD5 or SHA1 are no longer secure - you should generate a unique salt for each password and use Bcrypt to create a strong hash.
This article gives a decent explanation:
http://www.bentasker.co.uk/blog/security...
But doing a Google search yourself will gives you lots of results on storing passwords in databases.
You can change the Type to BINARY and give it a length of 60. If your application will remain private, using the MD5, SHA1, or the PASSWORD function is okay. A description of the encryption and compression functions are available in the official MySQL docs here: http://dev.mysql.com/doc/refman/5.5/...
May I know what you want here? You want to use SQL to encrypt your passwords? So, before saving the password, you call something like this?
select * from user where username='me' and password=md5($mypass)
If that is what you want, it depends on your SQL engine. MySQL has a function called MD5 to help you do the job.
I think the easiest is to edit your table,there should be a column called "Function". There you can select MD5 from a drop down list and then click GO, and any value stored in that Field will become hashed. So if you already have a password stored in your table, However if you try to change again the converted hashed text to CHAR, it will change the original password and putting the right password on the php side will fail
UPDATE Desarrollo.Login SET password = md5('mypassword') WHERE Login.id = 1;
I think this can help.
Related
Hi I have managed to implement container managed authentication in weblogic 12c with an SQLAuthenticator. I am successfully loging in with the users I create in the database when the password setting is set to PLAINTEXT in the provider specific sqlauthenticator settings and the database value is not encrypted.
If I am storing the user's password inside the database using the following code though I cannot login:
String encPass = "{SHA-1}" + new sun.misc.BASE64Encoder()
.encode(java.security.MessageDigest.getInstance("SHA1")
.digest(newUser.getPassword().getBytes()));
By providing the password "weblogic1" this value is stored in the db: {SHA-1}r49g3WeQasgoe6ODQ+5fa4Ic5tk=
In my SQLAuthenticator provider specific settings I have "Plaintext Passwords Enabled" set to false, "Password Style Retained" set to true, Password Algorithm: set to SHA-1.
When I run
request.login(email, password);
It throws the Authentication Failed exception...
What am I doing wrong?
A little late, but I think I can answer this one for you.
From the sound of things, your code was in fact correct, however, as you discovered, your tables were not properly set up.
When configuring your RDBMS authentication, it is assumed that you have three tables in your DB, they are:
users (username, password, description)
groupmembers (group name, group member)
groups (group name, group description)
I expect you were mostly there, but lacking the description column for the "users" and "groups" tables was causing your problems.
You can check out this link from Oracle's online documentation for more info:
https://docs.oracle.com/cd/E21764_01/web.1111/e13707/atn.htm#SECMG195
OK, my code now runs correctly but I don't know why. The only thing I changed is that I added some description columns to my tables and fixed my queries in the provider description accordingly. This shouldn't actually affect the login, just the user creation from the weblogic console which didn't work. Maybe weblogic just needed a few restarts IDK.
I'm new to Redis, I am now learning it by trying to make a login function.
Suppose I have a table named User (id, username, password) in traditional SQL database, what's the proper way to design the Redis store for a table, so that I may achieve some sql-style-query like "select * from user where username=xxx and password=yyy"?
Is it a good way to set the key: username+password and the value: username "root" password "admin" using Hash?
Redis is not a replacement for SQL databases. They have different purposes.
In Redis you should design based on how you will access the data.
See this SO question.
Also this tutorial by Simon Willison is very interesting even though it has some years.
I suspect your query doesn't actually need to be select * from user where username=xxx and password=yyy, but instead just looking up by username and then verifying the password is correct.
Using Redis you can store the user information by the username (this is your primary/unique key) and then in your code verify the password is correct. As #tadman has stated in the comments - please don't store passwords as plain text, that's a huge security hole right there
I have only FTP and MySql access parameters. My client didn't tell me the password to access the dashboard. How could I recovery it?
(I haven't email access, so I can't use the normal recovery and I can't contact my client before next 2 day...)
Copy the password hash of one of your customer (or create a new one) from ps_customers table to the password field of employee in ps_employee table.
PS: pub#prestashop.com customer is created by default, if still exists use that password hash. (Password for this customer is 123456789).
Use any free online MD5 generator like http://www.md5hashgenerator.com
but ecode COOKIE_KEY from settings.inc.php and new Password (with no space).
'COOKIE_KEYNewPassword' example 'bWZbVe5OEq4nwbWZbVe5OEq4nwbVe5OEq4nwnJI2xj8g3nAW1GC1y5KTwMyPassword’
Now cope your new password (MyPassword) to the ps_employee table in your database instead of the old pass.
In your database go and look at the table named PS_employee
While there add a new line with appropriate info and for password use this generator
http://www.md5hashgenerator.com
BR's
(don't forget to accept when this answer helps you )
In our ancient Classic ASP environment, we utilize OWASP to get the password from the request object and encrypt non-alphanumeric characters. This is a first line of defense to preventing sql injection. We use other methods for full sql injection prevention.
The problem is, when we are collecting data to put together an HTTP post message and just grab the password from the user input, OWASP it and send it along. The password is therefore incorrect.
Example: Password freddie$cougar becomes freddie&36;cougar
What we ended up doing was assuming that a 50 character text field was not enough space to do much sql injection and changed the code so we didn't OWASP the password coming in. This feels a bit scary.
Is their a better way?
The code is written in vbScript.
A better solution is to convert all queries to parameterized ones.
Here is a 12 year old article explaining how :)
Why are you sending the password in clear text? Calculate a hash value for the password and send that one. This would allow you to prevent SQL injection and to avoid man-in-the-middle type attacks.
In any case, you have to also clean up the data as it comes to your server. Even if your vbscripts does client-side validation, it would be trivial to attack your service by bypassing your script and hand-crafting a packet with malicious input in it.
Consider moving your SQL statements to stored procedures, and ensure that you don't use dynamic SQL within those stored procs.
Dim userPwd = Trim(Request.QueryString("userPwd"))
'--- Create and append parameter for Password
Set pwdParameter = cmd.CreateParameter("#UserPassword", ad_nVarChar, adParamInput, 50, userPwd)
cmd.Parameters.Append pwdParameter
Aside, it's definitely best to not even store the pwd in your database, but rather a salted hash.
The method above is preferred, no matter what string you're sending to your database, as it'll avoid executing directly as an adhoc statement, and will avoid SQL injection, as long as you're not using the parameter with dynamic SQL within the stored proc.
A lot of sites limit the set of characters that can be used in passwords - choose a set that is not going to cause you grief. That probably means alphanumerics, and some punctuation (comma, full stop, dash). Having suggested that, those sites annoy me - I use a rich set of characters in my passwords when given the chance to do so, and on the alphanumeric-only sites I usually end up using nonsense like 'IHateNoPunctSites' as the password.
What about shipping the password as a hex-encoded string, or a base-64 encoded string? You can then decode the string at the end, being as careful as necessary to prevent any injection without limiting the character set that is used in the password. When you need to check the password, you can ensure you are doing it cleanly using a parameterized query. Or you can hash the password with its salt before sending the query off to the password file. You should not be doing much with passwords anyway.
I currently have a database schema that contains a user's password in plain text. I've added a new column called password of type binary(16) with the intent of hashing the current plain text password via MD5. When I do this, I'm finding that the value stored in the password field is wrong. Here's my conversion query:
UPDATE my_table SET password=HASHBYTES('MD5', plain_text_password);
For one of my records, the plain text password is asdf. The correct MD5 value of this is 0x912ec803b2ce49e4a541068d495ab570. However, the record is being updated to 0xEC81AFD2DF2BDA47850F9182F4AC300D instead.
Has anyone every seen issues like this before? I'm using SQL Server 2008.
Update:
Thinking about this a little more, I converted the plain text password field from varchar(MAX) to varchar(50). It displays the same way within SQL management studio, but I'm wondering if the underlying encoding from when the data was in varchar(MAX) format somehow got copied over to the new varchar(50) format, causing the discrepancy.
So I figured out what was going wrong here. After I converted all the plain-text password fields (or perhaps this was true all along, I'm not sure) a bunch of \0's were appended to the end of the field. So instead of the word 'apple', it was 'apple\0\0\0\0\0'. SQL Management studio doesn't show these \0's, but the Visual Studio debugger did. After removing all the trailing \0's, my problem goes away.