Re:Database leak exposes 3.3M Hello Kitty fans
by DCoder on Tuesday December 22, 2015 @12:49PM
(#10779128)
Note that this approach can expose the user entered password in application debug logs, MySQL's slow queries log (if you're not using bind variables), etc.
Re:Database leak exposes 3.3M Hello Kitty fans
by nly on Tuesday December 22, 2015 @01:31PM
(#10779400)
That's true currently of any HTTP-level logs
Re:Database leak exposes 3.3M Hello Kitty fans
by DCoder on Tuesday December 22, 2015 @01:56PM
(#10779547)
Yes, it is, but that doesn't excuse doing it here.
Re:Database leak exposes 3.3M Hello Kitty fans
by dthakur on Tuesday December 22, 2015 @01:49PM
(#10779504)
If there are other ways to confirm whether a user exists or not (signup email check for example) --
I would add that the 'bonus' of not informing of the correct error provides minimal security gain and hurts usability.
Re:Database leak exposes 3.3M Hello Kitty fans
by nly on Tuesday December 22, 2015 @07:26PM
(#10781283)
> If there are other ways to confirm whether a user exists or not (signup email check for example) --
This would be a bug. There should be no way for someone with my e-mail address to determine if I use any particular service.
My POV is you should be able to verify user sign-in with something like "SELECT COUNT(*) FROM users WHERE email = '[email protected]' AND password='hunter2';", which has the added bonus of not informing the client whether the query failed because the user didn't exist, or because the password was wrong. Imho, all queries for the column content should simply fail.