0

My way of letting the user retrieve his password when he forgot it is via answering his security question, and when he got it right, it will echo his password. Everything's working, except when I start to click the view password button.

I know it isn't advisable to post much code, but I think you need to see everything in order to understand what is wrong because I too cannot figure it out. Thank you in advance for those who will help me :)

EDIT: So I will do it in a safest way, that's why I deleted my code. I have a new and maybe more "solvable" question. Sir Jay asked me to post it. This is my register page.

<form method="post" class="form-horizontal" action="signup.php">
     <input type="text" class="form-control" name="username" id="username" placeholder= "username">

     <input type="password" class="form-control" name="password" id="password" placeholder="password">
</from>

My sign_up.php

if(isset($_POST['submit']))
{

$username = $conn->real_escape_string(trim($_POST['username']));
$password = $conn->real_escape_string(trim($_POST['password']));
$new_password = password_hash($password, PASSWORD_DEFAULT);
$query = "INSERT INTO pending(username, password) VALUES('$username','$new_password')";
}

It's in the table pending because it requires admin's confirmation. and when the admin confirmed his request, data will go to users table. And in my login, different page will redirect depends on the position of the user whether he's member or batch-president.

louie
  • 51
  • 2
  • 9
  • 1
    You should never let a user retrieve their password, you should only offer a way to reset. If a user can retrieve, then someone clever enough and nasty enough can retrieve *all* of the passwords. – Jay Blanchard Apr 13 '16 at 18:22
  • [Little Bobby](http://bobby-tables.com/) says [your script is at risk for SQL Injection Attacks.](http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php). Even [escaping the string](http://stackoverflow.com/questions/5741187/sql-injection-that-gets-around-mysql-real-escape-string) is not safe! – Jay Blanchard Apr 13 '16 at 18:23
  • Please [stop using `mysql_*` functions](http://stackoverflow.com/questions/12859942/why-shouldnt-i-use-mysql-functions-in-php). [These extensions](http://php.net/manual/en/migration70.removed-exts-sapis.php) have been removed in PHP 7. Learn about [prepared](http://en.wikipedia.org/wiki/Prepared_statement) statements for [PDO](http://php.net/manual/en/pdo.prepared-statements.php) and [MySQLi](http://php.net/manual/en/mysqli.quickstart.prepared-statements.php) and consider using PDO, [it's really pretty easy](http://jayblanchard.net/demystifying_php_pdo.html). – Jay Blanchard Apr 13 '16 at 18:23
  • Please use PHP's [built-in functions](http://jayblanchard.net/proper_password_hashing_with_PHP.html) to handle password security. If you're using a PHP version less than 5.5 you can use the `password_hash()` [compatibility pack](https://github.com/ircmaxell/password_compat). – Jay Blanchard Apr 13 '16 at 18:23
  • I am using password_hash on my register page but I can't make it work on my login page. @JayBlanchard – louie Apr 13 '16 at 18:30
  • If you use `password_hash()` on the register page then you must use `password_verify()` on the login page. If you're using `password_hash()` *then there is no way* you can provide the user with their original password because hashes are one way streets. – Jay Blanchard Apr 13 '16 at 18:31
  • 1
    You're mixing MySQL APIs here, *why?* That alone's choking your code(s). – Funk Forty Niner Apr 13 '16 at 18:33
  • that's what i did, but it always echo `invalid username or password` @JayBlanchard – louie Apr 13 '16 at 18:34
  • Post the code from your register page. – Jay Blanchard Apr 13 '16 at 18:34
  • sure sir @JayBlanchard – louie Apr 13 '16 at 18:41
  • posted it sir @JayBlanchard – louie Apr 13 '16 at 18:47
  • You do not want to use `real_escape_string()` on passwords. That will cause verification to fail because escaping the password changes it. – Jay Blanchard Apr 13 '16 at 18:56
  • A couple of other notes: Allow users to use the [passwords / phrases](https://xkcd.com/936/) they desire. [Don't limit passwords.](http://jayblanchard.net/security_fail_passwords.html) – Jay Blanchard Apr 13 '16 at 18:58
  • oh, sorry. so should I use $_POST directly to my pw and hash it? @JayBlanchard – louie Apr 13 '16 at 18:59
  • Yes, that is correct. Read [this](http://jayblanchard.net/proper_password_hashing_with_PHP.html) and [this](http://codereview.stackexchange.com/questions/79668/login-with-password-hash). – Jay Blanchard Apr 13 '16 at 19:13
  • 1
    TBH, I'm having trouble trying to figure out what the question's about at this point and not seeing a solution provided. I must say though, that you're going about this the wrong way if this is a live or intended to go live site. What you should be doing is to use a separate table with unique tokens where the user is sent just that; a unique token where they click to confirm, and then they can reset their own password. If there are any errors, then you need to do that; check for errors with error reporting and MySQL's error function. – Funk Forty Niner Apr 13 '16 at 19:31

1 Answers1

0

The very logic of sending somebody their password upon forgetting it is flawed.

Consider this: They forgot their password. There is no need to send them the same password as it makes no difference, at this moment in time, what password they used in the first place. Either way, they've forgotten it. Whether you send them a new one or the old one makes no difference to the end-user requesting it. 'Cause really, they're not requesting a new password so much as they're requesting any/which/way to just login to your system. Password, no password, they don't care. Just give them an option to login now that they no longer can.

Instead, because you should never store plain-text passwords in the database, simply offer them a new password (pass-phrase*) to enter when they login again. A password-reset, so-to-speak. Then offer them the chance to change that newly appointed password upon logging in successfully should they choose to do so.

I know this might not directly assist you in your current issue at hand, but consider it a good piece of logic when developing new systems with regards to password-retrieval/forgotten passwords.

*A passphrase is something that's easy to remember, yet when done correctly, also has significant entropy. It's a natural grouping of words that form a phrase. Sending a user a new password like B@3!&O$$,$fs@ is ridiculous. Nobody remembers that. Not even for 10 seconds. But if you offer them a randomized, one-off, passphrase like red friendly monkey plays soccer yesterday (I just thought that one up!) then that's rather easy to remember. It has significant entropy, and is good to at least get the user logged in. You can then force them to change it if you so desire, according to the regulations you've bestowed upon your access logic.

Of course there are other methods aside from new passwords and passphrases that require tokens and such, which automagically log the user in without the need for them to enter a new password/passphrase. They are simply prompted to create a new password within the reset process. But that's another case and I'm outta time.

Community
  • 1
  • 1
mferly
  • 1,646
  • 1
  • 13
  • 19
  • i know very well that this isn't a good way of retrieving password, thank you sir, but i also tried like sending an email to the user who forgot his password but that didn't work for me, i wish i can still change this soon though. thanks sir! – louie Apr 13 '16 at 18:27
  • same here @JayBlanchard thanks to people like you guys who give such advise to newbies :D in that way we can be better :) – louie Apr 13 '16 at 18:28