something messed up with custom params and passwords login

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

creat326
Posts: 86
Joined: 13 Jun 2010, 09:50

something messed up with custom params and passwords login

Postby creat326 » 03 Apr 2011, 20:19

I have this simple code on the client:

Code: Select all

ISFSObject tr = new SFSObject();
        tr.PutUtfString("version", SmartFoxManager.instance.Version);
        tr.PutUtfString("gamePlayer", SmartFoxManager.instance.gamePlayer);
        tr.PutUtfString("gameVersion", SmartFoxManager.versionNumber);
        tr.PutUtfString("gameName", SmartFoxManager.nameGame);
        tr.PutUtfString("upass", SmartFoxManager.instance.password);

smartFox.Send(new LoginRequest(SmartFoxManager.instance.email, SmartFoxManager.instance.password, SmartFoxManager.zone, tr));



then on the server i print the values I receive, they 2 consecutives calls to the loginrequest will generate different encripted passwords.

To prove it, I added this code on the server side custom login:

Code: Select all

nick = (String) event.getParameter(SFSEventParam.LOGIN_NAME);
pass = (String) event.getParameter(SFSEventParam.LOGIN_PASSWORD);

trace("LOGIN " + nick);
version = obj.getUtfString("version");
            trace("VERSION " + version);
String unencripted=obj.getUtfString("upass");
            trace("UPASS["+unencripted+"] PASS " + pass);


same input should produce the same output right? no in here... everything matches except for the encripted password, check out the resulting log:

First call:
03 Apr 2011 15:37:49,552 INFO [pool-1-thread-2] Extensions - {dogfightEx}: LOGIN jsjjj@jdkd.com
03 Apr 2011 15:37:49,552 INFO [pool-1-thread-2] Extensions - {dogfightEx}: VERSION 1.4a
03 Apr 2011 15:37:49,552 INFO [pool-1-thread-2] Extensions - {dogfightEx}: UPASS[kaka] PASS 1043a422f0b64a3190dff43d7e188ed5


Second call, pay attention to the PASS at the end, and compare it to the UPASS (the original password, which is the same):

03 Apr 2011 15:38:35,854 INFO [pool-1-thread-2] Extensions - {dogfightEx}: LOGIN jsjjj@jdkd.com
03 Apr 2011 15:38:35,861 INFO [pool-1-thread-2] Extensions - {dogfightEx}: VERSION 1.4a
03 Apr 2011 15:38:35,861 INFO [pool-1-thread-2] Extensions - {dogfightEx}: UPASS[kaka] PASS 5d599dbee19353c3d26fb5cf2d4f3569


Same UPASS, different PASS...
Am I doing something wrong? is this a bug or we've found the first quantum computer in history?
grhwood
Posts: 116
Joined: 15 Mar 2011, 04:43

Re: something messed up with custom params and passwords log

Postby grhwood » 04 Apr 2011, 07:31

You can't use the password encrypted my the server nakedly ;). Instead use

Code: Select all

getApi().checkSecurePassword(session, clearPass, encryptedPass);


to compare the pass.

See http://docs2x.smartfoxserver.com/GettingStarted/howtos#item3
creat326
Posts: 86
Joined: 13 Jun 2010, 09:50

Postby creat326 » 04 Apr 2011, 09:31

@ghrwood i think you missunderstood the problem.
I already use checkSecurePassword to compare the encrypted password vs a clear password, which does what you are saying.

The problem is that the line you posted, returns "false", and that's how this post came to life. Investigating as to why it was "false", I managed to print the encrypted and unencrypted password on screen. Two consecutive calls with the same password would print different results.

Regards
rav
Posts: 82
Joined: 06 Dec 2010, 13:14

Postby rav » 05 Apr 2011, 08:50

creat326 wrote: Two consecutive calls with the same password would print different results.


because client api sends HASH(HASH(plain_password) + salt)

salt depends on current session (every time different). Server in checkSecurePassword method does the same with your password from database and tries to compare hashed password from client with generated on server.
User avatar
Lapo
Site Admin
Posts: 21119
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 05 Apr 2011, 10:17

Exactly.
No two sessions will have the same "secret key". Otherwise it wouldn't be secure at all.
More on how this works here:
http://www.smartfoxserver.com/docs/docP ... /index.htm
(It's an SFS1.x article, but the principle is exactly the same)
Lapo
--
gotoAndPlay()
...addicted to flash games
rav
Posts: 82
Joined: 06 Dec 2010, 13:14

Postby rav » 05 Apr 2011, 11:26

but seems sfs method is not 100% secured, because if hacker intercept 'Salt' and 'HashHashPassWithSalt' he'll be able to get 'HashPass' via bruteforce with this pseudocode:

String bruteforce_data = "a";
while(Hash(Hash(bruteforce_data) + Salt) != HashHashPassWithSalt)
{
bruteforce_data = increment(bruteforce_data);//try next password
}

//i've got it! your password is 'bruteforce_data'

it's not so easy but if your game is based on real money a lot of hackers will do it
User avatar
Lapo
Site Admin
Posts: 21119
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 06 Apr 2011, 08:55

For starters I have no idea how your idea works. You should explain all the steps to intercepting the key.
Btw, the key can be intercepted is not a problem :D
It could be even shown out on giant screen to the public, no big deal. What is transmitted is hash(key + password)
So the password is the sensistive piece. And it's stored in the head of the user who types it. So you either use a keylogger or you spy the guy from behind it's shoulders :D
Lapo

--

gotoAndPlay()

...addicted to flash games
rav
Posts: 82
Joined: 06 Dec 2010, 13:14

Postby rav » 06 Apr 2011, 10:21

ok, f.e. hash(key + password) called hashed_password

1.key - was sent by server via unprotected (not 100% protected) way
2.hashed_password - will be send by client via unprotected (not 100% protected) way

3.so key and hashed_password can be intercepted

4.

Code: Select all

while(true) {
   doSomethingWith(password_to_check);
   if(hash(key + password_to_check) == hashed_password)
   {
          //I know your password!!
          System.out.println("your password is: " + password_to_check);
          break;
   }
}


f.e. in doSomethingWith() password_to_check value changes:
1st iteration: "a"
2nd iteration: "aa"
3rd iteration: "ab"
and so on

at which point you do not agree with me?
User avatar
Bax
Site Admin
Posts: 4482
Joined: 29 Mar 2005, 09:50
Location: Italy
Contact:

Postby Bax » 07 Apr 2011, 07:52

Again, you should describe how you would intercept the key and the hashed_password.
Also, brute force attacks can be used with any password in the world. The question is: how much time will it take if the password is long enough an it's not made of vocabulary words?
Paolo Bax
The SmartFoxServer Team
rav
Posts: 82
Joined: 06 Dec 2010, 13:14

Postby rav » 07 Apr 2011, 14:12

bax wrote:Again, you should describe how you would intercept the key and the hashed_password.


Everybody who has access to network equipment can do it (sniff traffic) (game administrators, corporate's administrators, privider's administrators,...).

If in your game main prize is "gems" scarcely anybody will do it, but if it's real money?! there will be a small army of wanting
Democre
Posts: 77
Joined: 16 Sep 2010, 17:58

Postby Democre » 07 Apr 2011, 15:20

I think rav is being sensationalist. Is this system totally 100% secure? No. Nothing is. Is it secure to reasonable and usual expectations? Yes and then some.

I'm sure there are banking systems that use this system or a derivative. They are not games, sure, but they do use real money. Why are people's accounts not being drained?

You're talking about stealing one person's set of keys, for their personal lock. If a game was for money, you'd have to find the right person to steal their keys. You'd have to sniff their traffic. (needle in a haystack close to server, or sitting on their network near their house). You'd have to give time for brute force (depending on password strength could take a long time(weeks or months, even years)) You'd have to extract the money in some untraceable way.

It just becomes laughably unprofitable when you start thinking about getting money from a game in this way. What happens if you are discovered and that account gets banned? No more money, you'd start all over again with another account. (not to mention possible criminal or civil charges)

It'd be easier to just play legitimately, or try through other ways to run your scam. This perimeter guard is not the weak link.

sorry for the rant
-Andy
User avatar
Lapo
Site Admin
Posts: 21119
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 07 Apr 2011, 15:31

2.hashed_password - will be send by client via unprotected (not 100% protected) way

Yes but this is not reversible! And this is why it can be sent in clear. :)
An hash algorithm is a one-way only encryption system.
Once it is encrypted you can't go back to the original data.
Please, read the docs ;) And still in doubt please do take some time to research on this topic. Let Google be your best friend :)
Lapo

--

gotoAndPlay()

...addicted to flash games
ext0sus
Posts: 71
Joined: 17 Oct 2010, 16:14

Postby ext0sus » 07 Apr 2011, 19:26

WARNING: Long-winded post incoming.

AFAIK, packet sniffers will only work if you are connected to their network- I could be wrong though. So you'd either need to attach your computer to their router (easier with wireless) or install software on their machine to do it (in which case, why not just install a keylogger and get their clear-text password)

Either of these scenarios are very unlikely, even in a game for real money.


Also I'd like to put the idea of bruteforcing into perspective for anyone concerned about this kind of attack (using the long-scale naming system (1 billion = 1 million million)):

Firstly, the number of possible passwords is described as x^y where x is the number of characters than can be used in the password and y is the length of the password.

Now, lets assume your application allows passwords of length 6-18 characters and allows you to use a-z, A-Z, 0-9 (62 characters total). For simplicity, we'll miss out punctuation (bear in mind that each additional character increases the number of possible password combinations exponentially)

That's 62^6 + 62^7 + ... 62^18 = 190 000 000 000 000 000 000 000 000 000 000 possible combinations.

At 100 million combinations per second, it would take a single machine 59 000 000 000 000 000 years (59 thousand billion years) to exhaust all possible combinations.

Lets say, on average, you'll get the correct password at the half-way mark. That's a mere 29 thousand billion years to get the password (only 29 thousand million years if you're running a million machines)

Fun fact: from the single-machine time estimate above, the account would need to be worth £360 trillion for the money-per-hour from bruteforcing its password to be equal to the UK minimum wage.

Yes, it's possible to get the correct password in one shot but you're more likely to be dead long before it finds the right one.


TLDR: Bruteforcing isn't a feasible method of obtaining someones password. It's a non-issue. Don't worry about it.
rav
Posts: 82
Joined: 06 Dec 2010, 13:14

Postby rav » 13 Apr 2011, 12:38

partly you are right.. Bruteforcing stop working when password contains more than 9-10 characters, but there are more efficiently ways (f.e. using dictionaries)

NB: users very often use 6-8 character passwords
ext0sus
Posts: 71
Joined: 17 Oct 2010, 16:14

Postby ext0sus » 13 Apr 2011, 13:45

rav wrote:partly you are right.. Bruteforcing stop working when password contains more than 9-10 characters, but there are more efficiently ways (f.e. using dictionaries)

NB: users very often use 6-8 character passwords

Forcing users to supply at least 1 number in their passwords will make dictionary attacks a lot less powerful. Developers can't be responsible for their user's not choosing sensible passwords - the best we can do is impose restrictions (as described above) or advise them on how to create a secure password. Quoting someone from a post I read recently: "There's no way to protect against simply trying every possible combination."


And even with just 6-8 digits (still using a-z, A-Z, 0-9), that's 62^6 + 62^7 + 62^8 = 221918520426688 possible combinations. At 100 000 000 combinations per second it would take about 25 and a half days to exhaust all possible solutions (with a reasonable chance of no match at the end of it).
[EDIT: I wrote a simple C# application that would generate combinations and output them to the console. On my mid-ranged PC, it only managed 6348 combinations per second - making my estimations almost 16000 times faster than they would be. Granted, I didn't expect any machine to test 100 million combinations a second realistically.]

That's assuming that they've went through the trouble of intercepting your messages to the server in the first place. If they didn't - they'd have to use the login form as normal. Since alot of services lock users out for ~15mins after 3 failed login attempts, that would be ~2 111 097 036 years for a simple 6-8 digit password.


It's still far too much trouble to go through - even for games that offer real-money prizes.

This question on stackoverflow has a couple of interesting responses on the subject:
http://stackoverflow.com/questions/2771 ... -algorithm


But in the end, we've all got to remember: no matter how awesome we think our game is, it's just a flash game. The kind of methods we're talking about would take a lot of effort and dedication and would almost certainly not be employed on any game. If you want to make money from an online game, it would be 100 times easier and more profitable to code a bot for it (or a keylogger to grab clear-text passwords). No hacker in their right mind would try to brute-force a password - they'd be very lucky to get anything from it.

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 9 guests