View Issue Details

IDProjectCategoryView StatusLast Update
0000126The UnderworldBugpublic2024-01-29 01:38
Reportershare Assigned To 
PriorityimmediateSeveritymajorReproducibilityN/A
Status closedResolutionno change required 
Summary0000126: Client side password hashing
Description

[Original subject was: "Uh, do not send passwords to the server in plaintext?"]

What more can I say, just, don't. Use a cryptographically secure hashing function on the client and then send that over to the server. The fact your server has the plaintext passwords in transmission is alarming and we made an account of share:share because that is sketchy as heck.

TagsNo tags attached.

Activities

SkyCorp

2024-01-29 01:34

administrator   ~0000227

Last edited: 2024-01-29 01:38

Hello,

1) Account sharing is not permitted. Only one person is permitted per account, and publicly posting the password is not allowed. As such, I have reset the password on this account and you will need to change it via the forgot password page should you wish to use it again.

(Note that usually account sharing / password sharing is cause for a ban, however, that is not being done in this case as this seems to be in connection with a well intentioned security report. In future, if there is a security issue where you feel it is necessary to report the password, please report that privately. There is a private checkbox on the issue report page, or e-mail/discord/etc all work, too)

2) Passwords are cryptographically secured on the server side via PHP's standard password_hash() function.

https://www.php.net/manual/en/function.password-hash.php

As logins are done with SSL, there is not a risk of password leakage. This is how the majority of consumer-grade websites function.

While it is technically possible to add additional hash on the client side (as you suggest) with javascript, adding another potential point of failure adds risk:
1) The client side hashing function might result in a less secure result that is passed to the server
2) There may be some exploit to the client side hashing function or some other attack vector
3) The client side hashing function might have to be changed at some point due to the above or another reason, causing all old user passwords to be invalidated, potentially permanently locking large numbers of people out of their accounts should they no longer have access to their original e-mails.

Because of that, my intent is to keep the login code simple and secure by using the same logic as is used by the majority of websites. Ie: Regular login form on client -> SSL -> standards based password_hash() on server.

This is not 'sketchy,' this is the standard implementation. Relying on non-standardized clientside Javascript for security instead of auto-updated, widely deployed & well tested server code is not the way.

Issue History

Date Modified Username Field Change
2024-01-28 19:43 share New Issue
2024-01-29 01:34 SkyCorp Note Added: 0000227
2024-01-29 01:35 SkyCorp Status new => closed
2024-01-29 01:35 SkyCorp Resolution open => no change required
2024-01-29 01:35 SkyCorp Summary Uh, do not send passwords to the server in plaintext? => Client side password hashing
2024-01-29 01:36 SkyCorp Description Updated
2024-01-29 01:38 SkyCorp Note Edited: 0000227
2024-01-29 01:38 SkyCorp Note Edited: 0000227