So as I was playing around with php and security, I couldn't help but think about a major flaw that just jumped into my mind...
What the fuck does the client/server do with the passwords???.....
No really.... I made a whole secure registration page with hashed salted passwords just to realize.... the client/server probably has no clue how to resolve it.
Now I'm like DAYUUUM wadafuk.
Since I have no clue about how aura (yes I've never even bothered downloading aura) or the official files handle passwords.
And I never logged mabinogi packets :<
My guess would be the client sends it out without any decryption. The server recieves the password -> hashes it and then checks with the password in the database.
^ If that is true then I hope I can somehow add salts to the server.
And I also just realized that this could be a huge security risk depending on how the server handles the unhashed password.
OR maybe im just too tired and don't know how to think anymore.
Everything is possible-
Salts and Hash
-
Yoorah
- Site Admin
- Posts: 2318
- Joined: Wed May 13, 2009 12:31 am
- IGN(s): Yoorah
- Server: Ruairi, Mari
- Contact:
Re: Salts and Hash
Not really sure what your question is. Depending on how the server ____ -> security risk = true for most things. :P
Generally, hashing isn't used to protect the password when it's submitted to a web server. The main goal of hashing is for the server to not store plaintext passwords. This is why many web services providers like email sites had HTTPS protected login sessions even long before using HTTPS all the time became a standard. The only purpose of the salt is to then make the stored hash more difficult to reverse.
There are of course various ways of not sending the password in plaintext: Think about how SSH, IPSec, PGP, etc implement authentication. In your case, if you want to protect your users' passwords from network snooping attacks, you'd need to get a SSL cert for your site. Not sure how Mabi does authentication, though. IMO it's not worth worrying about so long as the server hashes and salts the plaintext passwords properly.
If you're interested in the PHP side of things, check out this page if you haven't: http://www.openwall.com/phpass/
Generally, hashing isn't used to protect the password when it's submitted to a web server. The main goal of hashing is for the server to not store plaintext passwords. This is why many web services providers like email sites had HTTPS protected login sessions even long before using HTTPS all the time became a standard. The only purpose of the salt is to then make the stored hash more difficult to reverse.
There are of course various ways of not sending the password in plaintext: Think about how SSH, IPSec, PGP, etc implement authentication. In your case, if you want to protect your users' passwords from network snooping attacks, you'd need to get a SSL cert for your site. Not sure how Mabi does authentication, though. IMO it's not worth worrying about so long as the server hashes and salts the plaintext passwords properly.
If you're interested in the PHP side of things, check out this page if you haven't: http://www.openwall.com/phpass/
-
Ainna
- Rank D Shadow Commander
- Posts: 32
- Joined: Sat Jan 31, 2015 1:16 pm
Re: Salts and Hash
Yeah the question came up as I finished my php registration with hashed salted passwords.
I was wondering if the server files could actually resolve the passwords of the custom login/register page or if there would be a way to change how the server files handle the passwords.
So if I create a password with my registration page then -> password gets salt -> gets hashed -> hashed pw gets hashed further.
But I was uncertain if the server would actually know what to do with these passwords. And I really won't know until I see the server files.
In order for this to work, the server files would have to use the salt from the registration, then hash the same way the page did and check with the hashed pw in the database.
I was wondering if the server files could actually resolve the passwords of the custom login/register page or if there would be a way to change how the server files handle the passwords.
So if I create a password with my registration page then -> password gets salt -> gets hashed -> hashed pw gets hashed further.
But I was uncertain if the server would actually know what to do with these passwords. And I really won't know until I see the server files.
In order for this to work, the server files would have to use the salt from the registration, then hash the same way the page did and check with the hashed pw in the database.