Swag and his password stealing

[Let'sPlay]

Swag didn't think I'd make this post, did you bud? Well I did, and by the way. Swag has been stealing passwords from innocent victims on Armagetron Advanced he just threatened me of stealing mine with his techy-shit and he has already stolen Kevon@forums' password. He is a friend of mine and right now and this very moment, Swag, is commanding me to login so he can steal my password. I would just like him to stop and/or you to ban him or make him stop stealing passwords along with trolling! Thank you very much, best regards, Play.

[LOVER$BOY]

Firstly
You double posted the same topic. Not good...

Now to the topic
We are already aware of what swag does and are getting many complaints about him. Your friend isn't the only one who got his password stolen. There are several people within the forums here who got their passwords stolen by him, especially Nelg.

Now onto dealing with him... that's hard. In servers there is this ban feature which can ban you ip address. That is good and all but he keeps changing his ip adress. Then he does these proxy stuff and all, making it difficult to pin-point on him.

Others
Let's wait and see what others have to say to this since we did discuss recently his actions

[Z-Man]

Thanks for making me clean up after you.

We deliberately do not have a global ban system. We can make his life a bit harder by making the master servers ignore him, but we cannot prevent him from entering servers we do not control. Talk to the admins of the server of your choice to get him banned there. They should not need my approval to do anything, but if they feel better, they can have it.

If he does not control the server in some fashion, he can not steal your password unless you give it to him. Other clients do not see password related communications.

If he does control the server,
a) yes, he can steal weak passwords by brute forcing the hash that goes over the server. Not much we can do about it. (Not nothing. Authority to client encryption transparent to the server, more expensive hashing schemes, token based authentication where the client directly talks to the authority.)
b) what are you doing there? Get out!

[Light]

If he does not control the server in some fashion, he can not steal your password unless you give it to him. Other clients do not see password related communications.

That was my main point when you posted in Rx.

yes, he can steal weak passwords by brute forcing the hash that goes over the server.

I avoided saying what could be done just because it probably wouldn't be too tough with a little Google. Hell, I can come up with two pretty easy ways off the top of my head.

token based authentication

I don't think this would solve much. Returning the expected data wouldn't be hard. You could have a token be sent and the only difference would be adding an extra step to the brute forcing. Being open source and having auth scripts publicly available, I can't really think of a good solution.

[Z-Man]

token based authentication

I don't think this would solve much. Returning the expected data wouldn't be hard. You could have a token be sent and the only difference would be adding an extra step to the brute forcing. Being open source and having auth scripts publicly available, I can't really think of a good solution.

Given this was just a quick remark, I did not make myself clear. What I mean by token based:
Client to Authority: "Hey! It's me, Z-Man@forums."
Authority to Client: "Prove it. Send your password hash, hashed again with this nonce."
Client to Authority: "Here you have it! You're welcome!"
Authority to Client: "Acknowledged. Have this token that I just randomly generated."

Client to Server: "Hey! It's me, Z-Man@forums."
Server to Client: "Prove it. Send me your token."
Client to Server: "Whoa, not so fast. I will send you a hash of the token, here."
Server to Client: "Whatever. Wait while I check it."

Server to Authority: "Some bozo claims to be Z-Man@forums. He send this token hash as proof."
Authority to Server: "That hash matches the token I gave out to a client who proved to be Z-Man@forums."
Server to Authority: "Oh? Well, that is unexpected."

Server to Client: "You're clear. Enjoy your stay."

Obvious details left out: Client to Authority communication needs encryption, token check should follow the same anti-man-in-the-middle mechanism as the current auth; essentially, the token should be treated exactly like a one time password.

[Light]

I assume the token would have an expiration so it could update every so often? What may even be better is if a new token were generated each time you logged in, and stored for your next authentication attempt. Of course, you would probably want to go directly from client to authority, and the other way around. That may be a bit excessive though. Maybe a login limit, like three times or something if not manually updated. Either way, that would keep the password hash safe from MITM, which sounds good.

Seems like the idea could work, but seems difficult to get there too easily. If my thoughts are correct, we would need an updated client, authorities would need to update their scripts, and databases would need modified to add the token column. Getting people to change is never easy.

Are these ideas that you're actually thinking about implementing though?

[takburger]

What about:

client to authority: "here are my hashes and i'm playing at this ip, plz tell the server that i'm the real takburger".
authority to server: "some player claims to be on your server with this ip and this name, you can grant him privileges due to his user level"

but i'm no good in such stuff, maybe it is not possible... I wanted to cut the server from the process for certain type of commands.

[Light]

What about:

client to authority: "here are my hashes and i'm playing at this ip, plz tell the server that i'm the real takburger".
authority to server: "some player claims to be on your server with this ip and this name, you can grant him privileges due to his user level"

but i'm no good in such stuff, maybe it is not possible... I wanted to cut the server from the process for certain type of commands.

It would be possible, but would allow for spoofing authorities and easily gaining "access" to other users' logins. They wouldn't really have access to it, but the server would consider it the same. The positive thing about the server handling some of it is that the server knows where it's requesting from.

[Z-Man]

Yes, the token would expire. What I forgot to point out: BAD passwords can be brute forced. The token would essentially be a randomly generated good password and even if the transport from client to authority stays the same as for the passwords, security is greatly enhanced for the average user.

Seems like the idea could work, but seems difficult to get there too easily. If my thoughts are correct, we would need an updated client, authorities would need to update their scripts, and databases would need modified to add the token column. Getting people to change is never easy.

Precisely right! Especially, with the right method, servers do not need to be updated.

Are these ideas that you're actually thinking about implementing though?

No, not really. What we can do realisitcally would be a move to a more expensive hash function. Iterate over some md5 scheme a configurable number of times and that is how much harder you make it for brute force attacks.

[Light]

Iterate over some md5 scheme a configurable number of times and that is how much harder you make it for brute force attacks.

I don't think that would really do much from the side of a brute forcer unless you want to slow them down. On another note though, wouldn't this actually hurt the security?

We know that MD5 hashes are not always unique from different strings. It's rare that it's a problem, but it does happen. Now, if you were to go over it a bunch of times, wouldn't you just be narrowing it down? It seems like the ones that do conflict would more easily come together when it's repeated over and over. Not sure if that would ever be necessary to worry about for a community this small, but then again I can't picture in my head that many different combinations.

It would be cool to see something like the token idea implemented though. There are so many possibilities with it. I know it's not exactly a top priority to worry about that stuff though since there's not really enough players here to worry about it being much of a problem.

I think we've fallen off topic of the post though. I highly doubt he's gone through such trouble to get them off of people who have been known to give out their passwords. I mean, it took him forever to figure out how to modify the chatbot, and he's begged so many times for help. I assume someone probably just finally helped him, but maybe he figured it out himself. Even so, doing this would be a bit more difficult since he would have to write some of the code himself. I just don't see it happening.

The people around here that I know can do it, probably wouldn't. I just liked the idea of having that upgraded since it's something I've thought about in the past.

On a side note .. Happy Thanksgiving in a couple hours. (:

[Z-Man]

Iterate over some md5 scheme a configurable number of times and that is how much harder you make it for brute force attacks.

I don't think that would really do much from the side of a brute forcer unless you want to slow them down.

By definition almost, that is all you can do against brute force attacks if you can't avoid the attacker peeking in on the authentication communication. And it is enough for sensible passwords. It is quite amazing how many simple hashes dedicated crackers can try through per second, but they still have to try through all passwords their human simulators come up with. If they can crack your password in a day, slowing them down by a factor of 1000 alone is enough to keep you save if you change your password once a year.

On another note though, wouldn't this actually hurt the security?

If you overdo it and build a bad iteration, yes. In a way, however, collisions increase security. We use nonces in the process, remember? So if I brute force your password hash and determine that the password "arglbarlg" produces the exact same final hash as the one you sent today, if there was a collision, that may not have been your true password. And on the login I want to fake, I get a different nonce and no longer produce a valid hash from the wrong password.

[delinquent]

Would prefixes and suffixes solve the problem? I.E. making this a requirement for authentication?

[Light]

Would prefixes and suffixes solve the problem? I.E. making this a requirement for authentication?

No. They can be seen in a browser window because the client has to request them, and they're returned in plain text. It wouldn't do anything to slow anyone down.

[kyle]

This is kind of related https://www.grc.com/haystack.htm regarding password security / brute force attacks

[Z-Man]

Suffixes containing the username token help against mass password cracking should the database with the hashes get stolen. If all password hashes are computed from only the password in the same way, you only need to hash each password you want to try once, then compare it to all the stored hashes.
But for individual passwords getting cracked with data that went over the net, no, they do not help one bit.