While setting up password for mysql i used the wrong code
update mysql.user set password=PASSWORD=('password') where user='root';
Here PASSWORD has been set to a value which i am not able to identify .I have tried safe mode recovery too,but the problem is not being solved.How to rectify this?
I have tried safe mode recovery,but there also the old password was required.
We can work this out by reproducing the problem in a toy example:
CREATE TABLE Foo (Bar TEXT);
INSERT INTO Foo VALUES("Hello world");
SELECT * FROM Foo;
UPDATE Foo SET Bar=BAR=('password');
SELECT * FROM Foo;
(live demo)
The first SELECT shows us Hello world; the second shows us 0. So, for whatever reason, the mistaken expression BAR=('password') resulted in 0. Therefore I believe the hash of your password is 0.
Trouble is, this doesn't really help you, because you'd need to know the password that maps to said hash — and it's likely that there isn't one.
You should just reset the root password, by spinning up the server with the --skip-grant-tables switch (disabling auth checks), then log in and set your password properly (ref). Be sure to restart it in "normal" mode afterwards, because that switch is dangerous! In fact, I suggest closing your firewall to incoming MySQL connections for the duration of the task.
Related
I am trying to verify user login my matching the input password to the password input by user
My insert query:
insert into login (Emp_id, Emp_Fname, Emp_Lname, Username, Password) values (5, 'TestFName', 'TestLName', 'Test', password('april'));
it stores the password as this value :
*72B46CDA233C759A88BEF81F59F66D78B26B2848
select * from login where password = '*72B46CDA233C759A88BEF81F59F66D78B26B2848'; -- this line shows me the result
select password('april'); -- this returns *72B46CDA233C759A88BEF81F59F66D78B26B2848
select * from login where password = 'password(april)'; -- this returns an empty set
Is there any alternative to this line of code?
I think you need to use:
select * from login where password = password('april');
So, don't quote the whole password function, just the argument to the function.
One cannot safely store passwords with pure SQL commands, instead a dedicated password-hash function of the development language should be used. In PHP this would be the functions password_hash() and password_verify() for the verification of the password.
Even more, MySql's password() function was never intended to be used with user passwords and is deprecated (will be removed in future versions). Have a look at the second note box in the documentation.
The reason why you cannot left the hashing to the SQL command is, that salted password hashes cannot be searched for in the database. The searching has to be done by user name only and afterwards one can verify the found password hash with the user input. A more in-depth explanation you can find in this answer.
https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_password says:
This function is deprecated as of MySQL 5.7.6 and will be removed in a future MySQL release.
PASSWORD() is used by the authentication system in MySQL Server; you should not use it in your own applications.
That wasn't an idle warning. https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html#function_password says:
This function was removed in MySQL 8.0.11.
So don't use PASSWORD() — unless you plan to never upgrade to MySQL 8.0.
Besides that, you have some problems in your code.
insert into login (Emp_id, Emp_Fname, Emp_Lname, Username, Password)
values (5, 'TestFName', 'TestLName', 'Test', password('april'));
I wouldn't use password (or any other hashing function) in this way, because you still have the plaintext password in your SQL statement. This ends up getting logged in query logs and statement-based binary logs, so it's a security weakness. That is, anyone who can get access to your logs can inspect the passwords.
Instead, hash the password in your app, and then put the result of that hash into your SQL statement.
Which hashing function you use depends on the language you use to write your application code. #martinstoeckli mentions a couple of functions that are used by PHP developers, but those won't be the same for other programming languages. You don't mention which language you use.
Likewise, when you search for a login that has that password, it works if you search for a specific hash string, but this doesn't work:
select * from login where password = 'password(april)'; -- this returns an empty set
The reason is that you're searching for the string 'password(april)'. Putting an expression in quotes means to use that literal string — it won't execute the function and use the result of it.
Again, you don't want to calculate the hash using SQL anyway. That puts the plaintext password into query logs and is not good for security.
You want to produce the hash string in your app, and then use the hash string in searches, like your first example. But not using the PASSWORD() function — using some application code function.
select * from login where password = '*72B46CDA233C759A88BEF81F59F66D78B26B2848';
(The hash string above is based on your example. It's a hash produced by MySQL's PASSWORD() function, only as strong as a SHA1 hash, which is known to be unsuitable for passwords.)
Actually, my preferred method is not to search for a password at all. Search for the login, and return the password hash string that is stored in the database.
select password from login where user = 'billkarwin'
Then in the application code, compare the hash string you fetched from the database against the re-calculation of the hash string based on the user's input when they're trying to log in.
Trying to copy a zencart website in another server, but after openning the right port and copying the database, i have this error while openning the url in an internet browser.
0 DB_ERROR_NOT_CONNECTED
in:
[select * from project_version WHERE project_version_key = 'Zen-Cart Database' ]
If you were entering information, press the BACK button in your browser and re-check the information you had entered to be sure you left no blank fields.
Does'nt anyone already encounter this error ? Or have suggestion of how to solv this ?
Tx
Something in includes/configure.php is wrong. Check each of these values very carefully:
define('DB_PREFIX', '');
define('DB_SERVER', 'localhost');
define('DB_SERVER_USERNAME', '');
define('DB_SERVER_PASSWORD', '');
define('DB_DATABASE', '');
You likely have a typo in one of them, or perhaps you forgot to specify the prefix.
For anyone which encounter the same problem.
It comes from the fact that the password were saved in an old format on mysql.
You should migrate them to the new format to solv this issue:
update user set password=password('<my_password>') where user = '<my_user>';
flush privileges;
I have a db that I'm calling "my_db". I'm trying to connect to it with Symfony2, but it keeps telling me this:
"Unknown database: "MY_DB"
What I did:
First I tried to modify the config.yml, and parameters.yml, to change the db name, since it seems to be in capitals in the error and the db name really isn't. The name in the config.yml was already in lowercase, but in parameters.yml(which I don't even use for this) it was in capitals. I changed it to make sure, but nope.. Nothing. Still same error. And yes, I cleared the cache.
Then I changed the actual mysql-database name to uppercase in phpmyadmin: "my_db" to "MY_DB", and tadaa: it worked!
Wait But Why?
There is something I'm missing here, since the names are all correct in the settings, but the problem didn't go away until I changed the database name to match the name in the error.
First it didn't work and I didn't know why. Now it works and I don't know why.
I need to know why this happens, so that nothing weird happens when I go to production later.
It's not a problem of Symfony or Doctrine, it's a problem at the database level, somehow your database is case sensitive, I think there's a way to change that by setting the lower_case_table_names system variable, read more about it here : http://dev.mysql.com/doc/refman/5.6/en/identifier-case-sensitivity.html
What's the SQL command to undo:
USE db;
The syntax I see everywhere is:
USE [db] ;
implying that I can leave out the db part. Not so - this is a syntax error however (maybe just syntax errors in the SQL syntax syntax?).
edit
The programming problem this is causing is that I can't reset the environment in which subsequent commands run. I could reset my DB connection, but this seems efficient.
cmdX; // Works
vs.
cmdX;
cmdY; // May fail because command X upset some state.
cmdX should clean up after itself and put things back where it found them.
Analogously:
cd ./a
doX()
cd ../
doY() // Y expects to not be in a?
I don't think you can. The documentation doesn't say the parameter is optional. It says:
The database remains the default until the end of the session or another USE statement is issued:
So if you want to drop the default, end your session and start a new one without selecting a DB.
What programming problem is this causing for you?
The database argument is not optional.
mysql> use
ERROR:
USE must be followed by a database name
I'm not sure where you saw this command with square brackets around the argument. That is not shown at the documentation page: http://dev.mysql.com/doc/refman/5.6/en/use.html
Microsoft SQL Server uses square brackets around identifiers (as opposed to a style to indicate an optional argument), but the MS SQL documentation for USE also doesn't show it: http://msdn.microsoft.com/en-us/library/ms188366.aspx
What would it mean to "undo" a USE command? Would it be like cd - in bash, making the previous default database again the default? There is no such command in MySQL for this. It doesn't remember what was your previous default database. If you want to return, you just have to USE that database and name it explicitly.
I've implemented my mail server as dictated here.
It works perfectly fine. My curiousity revolves around entering users into the database and authenticating them
Running:
INSERT INTO users (email, password) VALUES ('sales#example.com', ENCRYPT('password'));
Multiple times will give a different hash for the encrypted password as its utilizing a random salt. I.e. If I enter sales#example.com three times with the same password each hash is different...
My question to this is, how is it that the Postfix server can actually authenticate the password when a user logs in via a mail client?
There isn't any problem per say as it works fine, more just to satisfy my curiosity so I can fully understand whats going on behind the scenes to properly authenticate the encrypted password.
Postfix compares the password from the database to a new encrypt done with the salt(password from db).
to encrypt:
update user set password = ENCRYPT('1234') where id = 1
to check password:
SELECT u.* FROM user u where u.email ='admin#dominio.com'
and ENCRYPT('1234', u.password) = u.password
Read man crypt: it returns the salt in the first two chars of the return value.
So the salt is not lost, you can compare the encrypted string to the result of crypt( 'pass', $first_two_chars_of_encrypted_value ).
You must use ENCRYPT('pass','salt') to force a salt, otherwise the salt is lost forever and you have no way of recovering it. Fairly pointless function without it. It's a terrible function to use, though, because the security is so minimal; use PASSWORD() or OLD_PASSWORD() instead.
ENCRYPT() uses the system crypt(), which may use all or only the first 8 characters, must be printable 7-bit ascii, generally uses 1 round of a DES-based hash, and is completely unportable. Avoid it.