Getting rid of sha_pass_hash?

[arrai]

Hi folks,

since a commit some months ago, we actually don't need sha_pass_hash anymore. v and s, which are stored since that commit persistently, are sufficient to authenticate a user.

To explain this issue, I refer to the SRP6 specifications. s is basicly some random number to prevent precalculated attacks and v is something(for detailed information have a look at the specs; it's not really important to understand the math behind it to get my point) to check whether a given password is correct.

It boils down to the following: Everytime a useraccount is created or updates his password, s and v are calculated and stored in the database.

But what about sha_pass_hash? The stanford document doesn't mention it (l is the username=login):

The host then keeps {I, s, v} in its password database.

Furthermore, it doesn't mention anything like SHA(UPPER(username):UPPER(password)), which is how sha_pass_hash is calculated. The alarming truth is that MaNGOS' sha_pass_hash is actually SRP's Cleartext Password.

That means, that anybody who has gained reading access to mangos.realmd can authenticate himself using a modified or non-standard client.

The obvious solution is to drop sha_pass_hash and thus enhance security. However, there are two problems which prevented this step:

* Many 3rd party applications use sha_pass_hash to verifiy user passwords. All of them would have to be adapted to use only s and v. I already wrote a php class which handles the cryptography, but it requires the GMP extension.

* There might be accounts which haven't logged in since that commit, thus s and v are null. Because it's impossible to generate them from sha_pass_hash using pure SQL, there would be the need for executing a script before applying the SQL update which drops the column. This would be either a php script or a c++ application.

So what's your opinion? security > usability?

[pelle]

i absolutely prefer usability

[XdK]

I voted for security but I think this is not very dangerous:

- Making a custom client -> there are not much people who can do this.

- Getting an access as a game master to mangos isn't the most dangerous thing. Most of the servers dump their databases and can import them if needed.

I'm more anxious about emails than I'm about passwords. Even if he (hacker) gets SHA password hash he can't find the real password so he won't be able to get access to other sites.

[kich0]

maybe an option in config would be the best...

SHA_PASS 0/1

aldo it would be messy

[fdb_]

Here is another point of view regarding the issue about the sha pwd.

Get rid of the sha pwd field and implement an additional feature in the realmd process. The additional feature would be a web service to let external apps to authenticate. The web service can be SOAP / XML-RPC or any other wide used technology.

Config params can be:

soap_srv = 0|1

soap_port = 8080

soap_user = mangos

soap_pwd = sognam

Using this or some similar ways to handle remote auth can be very interesting because of you can expose more than an authentication service but uptime / players ingame / account creation-deletion and many more...

There are some nice libs to handle the job:

- gSOAP http://gsoap2.sourceforge.net/

- XMLRPC-C http://xmlrpc-c.sourceforge.net/

Both are very stable, widely used, still maintained from years and portable.

But gSOAP provides some tools to generate the code skeleton (read the "getting started" web page on their website), it could be perhaps easier to use it instead of XMLRPC-C.

[freghar]

maybe an option in config would be the best...

SHA_PASS 0/1

Different database layout based on a config option? Oh well.

My suggestion would be to keep it there for another couple of months until next milestone and remove it afterwards.

On the other hand - if somebody forgets a password, how can anyone change/reset it? Making a tool for it would be really good

[DasBlub]

i voted yes as i prefer security. but maybe a special listener in the realmd which allows password change/check would be nice for those 3rd party systems.

altough this listener would require to have some security implemented too... (an srp6 handshake to change/validate another srp6 o_O)

[False.Genesis]

imho the config file option is the best. if its not used, it can simply stay empty. if someone needs the field, he could still turn the config option on.

(and to be honest, in my database i have even reimplemented cleartext passwords... they are never used, but get updated whenever a password is changed. good as reference if some ppl forget their password, really)

[fdb_]

imho the config file option is the best. if its not used, it can simply stay empty. if someone needs the field, he could still turn the config option on.

(and to be honest, in my database i have even reimplemented cleartext passwords... they are never used, but get updated whenever a password is changed. good as reference if some ppl forget their password, really)

I agree that the config param is a good solution, but in that case there is no removal of the sha_pass field in the DB.

Avoiding duplicate data is also one of the main aim and use of databases, so entirely removing the column could be a good enhancement to have a well formed DB.

[Patman128]

I was very sad to hear that this year will be the last year for the Tower of Terror race.. I love it.. I know that there getting rid of the race for the taste too. But I hope that they put in a night race in the fall. That is why we are coming down... If anyone has heard what there planning on doing please let me know....

Spambot?

Personally, I would rather not get rid of the field simply because I use it. However, if redoing it in PHP is not too difficult, I might do it this way.

[pelle]

imho the config file option is the best. if its not used, it can simply stay empty. if someone needs the field, he could still turn the config option on.

(and to be honest, in my database i have even reimplemented cleartext passwords... they are never used, but get updated whenever a password is changed. good as reference if some ppl forget their password, really)

i agree with you!

[epozdnyakoff]

So what's your opinion? security > usability?

Since there's an acceptable way (your class, actually) to validate passwords from within an php script, usability isn't affected in any noticeable way. Moreover, due to SRP being an infrequently used protocol it would dramatically decrease common cracking methods' (such as rainbow tables) effectiveness. But then comes robustness. Do you have enough experience with php doing bigint math to trust it in generating authentication information? SRP is no bubble sort, so you may end up with users frustrated being unable to log in. So I am against it for now.

[arrai]

I agree that the config param is a good solution, but in that case there is no removal of the sha_pass field in the DB.

Avoiding duplicate data is also one of the main aim and use of databases, so entirely removing the column could be a good enhancement to have a well formed DB.

I consent with you, redundancy is (in this case) a bad thing. However, we could use a trigger to truncate v and s once sha_pass_hash is modified. That way we would prevent contradicting data

The whole "make sha_pass_hash a config option" makes IMHO only sense if we keep sha_pass_hash even if it's disabled. I will reset the vote to allow that new option.

Since there's an acceptable way (your class, actually) to validate passwords from within an php script, usability isn't affected in any noticeable way. Moreover, due to SRP being an infrequently used protocol it would dramatically decrease common cracking methods' (such as rainbow tables) effectiveness. But then comes robustness. Do you have enough experience with php doing bigint math to trust it in generating authentication information? SRP is no bubble sort, so you may end up with users frustrated being unable to log in. So I am against it for now.

It's the first time I used GMP in php

To check robustness, I could write a test which generates random passwords and validates the generated v. It wouldn't prove correctness (we all know Dijkstra famous quote ) but make a failure less unlikely.

[fdb_]

Arrai, yes using triggers is interesting and is also a good alternative.

Can you tell us what do you think about the alternative using Web-Services to allow external auth ? (I am currently trying to make a PoC to expose some informations from the realmd tell me if you are interested in it).

[Patman128]

Wouldn't keeping the column in there defeat the point of the entire switch?

I mean, the problem is if they get access to the database, they can get into any account with a packet editor. As long as that field is there, nothing changes.

Would you mind posting this new PHP function for authenticating?

[arrai]

Can you tell us what do you think about the alternative using Web-Services to allow external auth ? (I am currently trying to make a PoC to expose some informations from the realmd tell me if you are interested in it).

I can't see how this is related to the ongoing discussion about sha_pass_hash; you could build such a service in both cases. However, I think it would be an overkill: A feature wich requires quite some work, creates an additional library dependency and is rarely used.

Furthermore, as DasBlub already mentioned, it requires some considerations about securing that web-service.

[fdb_]

I can't see how this is related to the ongoing discussion about sha_pass_hash; you could build such a service in both cases. However, I think it would be an overkill: A feature wich requires quite some work, creates an additional library dependency and is rarely used.

Furthermore, as DasBlub already mentioned, it requires some considerations about securing that web-service.

I understand this point of view.

Regarding the additional libs, yes it is mandatory in that case. But I do not think it is a problem. such kind of heavy project usualy use many libs, one more wont hurt (at least it is what I think). I understand also that some investigations should be done on the cross-compatibility between the libs if needed.

Regarding the security, it is not less important than the security included in the realmd but we have to consider that the web services are for admin tools and not called from the external network. For example, the admin can config the fw of his servers to only allow the WS being accessed from the webserver. Moreover the WS can be configured with user/pwd access, HTTPS, and can also use the server/client cert.pem file to fully authenticate each call.

[epozdnyakoff]

Regarding the additional libs, yes it is mandatory in that case.

No, it's not. You could implement a text template-based POX or RESTful interface and a socket server implementing a subset of HTTP. The latter is less than fifty kilobytes of code when done right. And it's not overkill, but a handy feature that'll reduce database load when building web services such as maps or online users list - you could export those through it and not fall in the Database-As-IPC antipattern. Remember the Antrix's statistics page that was implemented as a server's module.

Regarding the security, it is not less important than the security included in the realmd but we have to consider that the web services are for admin tools and not called from the external network.

Just relax, we're protected by the power of OpenSSL. No enemy can break through our encrypted channels, so why bother limiting our web services to localhost?

[fdb_]

No, it's not. You could implement a text template-based POX or RESTful interface and a socket server implementing a subset of HTTP......

True, I was considering using an external libs being mandatory to ease the dev.

By the way, both methods can be used (not at the same time of course). Your idea to use POX & REST is very good to produce small footprint and for the efficiency, but perhaps heavier than using a lib.

Just relax, we're protected by the power of OpenSSL. No enemy can break through our encrypted channels, so why bother limiting our web services to localhost?

I did not say neither mean restricting the WS to localhost, of course it can be bind to localhost if the realmd process runs on the same server as the webserver, but it is not limited to that behavior (in case you use multiple servers web/realm/world...).

[VladimirMangos]

Please, stop oftopic discussion in thread, or just removed all related posts.

[Derex]

For a third party developer, calculating s and v would be overkill.

Authenticating in a web page using s and v will also be overkill.

It could be solved easily using stored procedures inside the db, but I don't see 'normal' way to do this in mysql, for postgre using some of the pl/pgXX bindings it will be easy task.

[FragFrog]

The question you have to ask yourself here is: in what situation will dropping sha_pass_hash be usefull?

Someone with access to the sha_pass_hash will in almost all cases have direct (read) access to the database. This person will already be able to see just about everything and most likely also modify fields - after all, not many people create seperate read-only accounts for their applications, and there are even less cases when an application can suffice with read-only access. Even a webpage used for account signup will have an account capable of insert operations, and if that is the case, the user can already insert an admin account for himself.

So the question becomes: what can we prevent by dropping sha_pass_hash? We can't prevent someone from logging in since he can easily insert an admin account for himself. Finding out a users password is still very unlikely - after all, rainbow tables generally only list common words, or random words up to 8 ~ 12 characters, the username: password concatanation is usually longer. Really the only thing it prevents is someone logging in as someone else after he got a copy of the realm database somehow without having access to the database, but with enough knowledge to modify a client. That is a very, very small risk.

On the other hand, a dozen applications make use of the field - just about all of those will stop working. Not everyone has full control over their webserver either, so the additional PHP library might just be impossible to install for some people (our server for example has a seperate webserver for account related functions, to which I only have very restricted access). Additionally, there will have to come scripts / applications for both windows as well as linux to update those accounts without a v / s value - applications administrators will have to trust not to contain virii or malware. An all this is considering those applications work flawlessly - what if they contain a small bug that only occurs once every thousand accounts? And will there be well written examples for all used languages - in my case, this means JAVA - will someone write a good library for that? How about the Perl scripters out there? Or the C++ developers?

If your security is so far compromised that the database contents can be read by someone with bad intend, you have already lost. Dropping sha_pass_hash will almost never stop that person from gaining even more access to your server. It is the tiniest fraction of security that will cause a load of trouble for application developers and server admins everywhere. So no, as both an admin as well as developer I say please, don't drop it