Bitcoin Forum

Steps to reproduce:
1. Go to profile and change your password to something like 12345678"
2. Now logout and try to login again.
3. Notice that your new password 12345678"  and your old password don't work anymore.

Am I the only one who uses quotes in passwords?  :D

why did you choose 12345678" ?
this is a very boring choice... next time try something like 12345678"); DROP TABLE USERS;
it will be more fun :)

I think that the password gets double-escaped somewhere, but I haven't been able to find where this happens.

I was just about to say the same thing. When quotes or other odd characters cause strange bugs then that is a sign of potential vulnerability due to MYSQL injection.

Sometimes the password:


will let you log into anyone on a poorly coded site.

See this plaintext link for lots of info on this sort of thing: http://www.greensql.com/articles/backdoor-webserver-using-mysql-sql-injection

I do hope this gets attention from the admins before it does from the hackers.

http://imgs.xkcd.com/comics/exploits_of_a_mom.png
Clearnet - https://xkcd.com/327/

try 12345678\" as password ;) if not then 12346789\\", increase the number of \ :P

I determined previously that the password is escaped too much, not under-escaped. SMF does escaping in an absolutely insane way, though, so I haven't been able to figure out how to fix this. The password doesn't even need to be escaped because it is hashed, but SMF automatically escapes all GET/POST input, and then sometimes unescapes it or escapes it more later. It's very difficult to follow.

It could also be an unnecessary escape in the login code of course.

Maybe somebody changed the "magic_quites_<whatever>" in php.ini?

Most likely magic quotes would have no effect if you have the same input.

PW change would update password to: hash('12345678\"')
Login would check:  is hash('12345678\"') same as db hash => true

The problem is that it is escaped differently I guess.

Here's the same bug, older than dirt: http://www.simplemachines.org/community/index.php?topic=96927.0

It looks like the problem might be this in the LogInOut.php (http://www.phpkode.com/source/p/simple-machines-forum/Sources/LogInOut.php) module, where it potentially alters the password before hashing it:

  $sha_passwd = sha1(strtolower($user_settings['member_name']) . un_htmlspecialchars($_POST['passwrd']));

but then in other places are inconsistent, like Profile.php (http://www.phpkode.com/source/p/simple-machines-forum/Sources/Profile.php), in resetting password function we see it's missing the "un_htmlspecialchars" when hashing:

  if (!$good_password && $user_info['passwd'] != sha1(strtolower($cur_profile['member_name']) . $_POST['oldpasswrd']))
      $post_errors[] = 'bad_password';
   

What does that blue function do?:

Syntax
void un_htmlspecialchars (string $text)


Parameter $text

Expected type: String
Description: string to be have htmlspecialchars removed.

Notes

    removes the base entities (&lt;, &quot;, etc.) from text.
    should be used instead of html_entity_decode for PHP version compatibility reasons.
    additionally converts &nbsp; and &#039;.


I have had similar headaches with buggy password managers and such, when using type-able characters such as <, >, that they get interpreted, stripped, or truncated (or even better, put into HTML raw without converting to &gt; which breaks the HTML.)

There is no point in normalizing passwords that are going to be hashed, the hashing normalizes them.

This seems like a design flaw. un_htmlspecialchars does not belong there.

Nice bug report exxe! Thank you.

is this already fixed?