Passwords?

[FrOzeN]

I though of an idea, when making a bot it would be a good idea to check the username/password to see if there characters would even make a valid login (inclusive of iLLyz).

I know what can be permitted by Usernames, though I don't know what characters/orders are allowed for passwords. And with a bit of testing I wouldn't be able to find out what characters/orders old (from time of iLLyz) passwords used.

Anyone know much about them?

[UserLoser]

First off, "iLLyz"?  And passwords can have any character you want in it.  They're sent in a 256bit hash so it doesn't matter what you have your password as

[FrOzeN]

Well for example you can no longer make accounts with $ in it.

So say the bot logged on and account didn't exist, I would then run it through a check which would determine that account cannot be created because of that character and it would just Disconnect with an error message.

By "iLLyz" I was just using slang to refer to accounts that contained illegal characters and haven't been permitted to be created for quite a few years now.

Anyway you answered my question, I should know better considering my last two passwords contained § and †.

[Denial]

What the hell did he just say?

[Eric]

He wants to be able to determine if an account exists and if it doesn't, he wants to check the account name for banned characters before attempting to create it however the local implimentation of this would be pointless since both SID_LOGONRESPONSE2 and SID_CREATEACCOUNT2 have error responses which do exactly that.

[FrOzeN]

I know they have login responces for it. I just through it would speed up some of the authentication upon logging in, if all the basic checks have been done to that details being sent.

For example say someone connects with local hashing, first check if they have hashes before even bothering to go any further. Kind of alone those lines.

At that moment I was thinking that passwords have limitations on certain characters (not there max length, 12). This way it could be checked before connecting.

[shout]

At that moment I was thinking that passwords have limitations on certain characters (not there max length, 12). This way it could be checked before connecting.

On a side note, the lenth of a password is a client side thing. There is nothing in the protocol that has the length of the password transfered over network.

[Skywing]

Note that the game clients impose a limit on the number of bytes that a password can consist of - something along the lines of 12 or 14 if I recall correctly.  Game clients also use a locale-specific lowercase transform (as I recall, the exact function used was CharLowerBuffA, which has a behavior dependent on which locale you have configured locally).  Passwords that do not meet these criteria will be unusable through the game clients.

The chat gateway also imposes some of these restrictions on passwords; for instance, the chat gateway will lowercase all passwords.  This implies that if you have an exotic locale that does not match the chat server's locale, your password may not be usable via the chat gateway.  The chat gateway may also have an arbitrary limit on the length of a password, though I don't recall for certain.

There are different restrictions and transforms applied to passwords used with the SRP-based system.

[Tazo]

congratz skywing you went almost 2 months without posting!

[Yegg]

What happens if you implement this into your bot and the user decides that they want to log in and create an account on a private Battle.net server. Such as a PvPgn server? Often times these servers support "illegal" characters that the regular servers do not. Checking the account before they actually connect would really be a useless feature. The user should know what they can and can't use in an account.

An idea that could possibly save time when connecting could be:
 
   Decode cdkey's immediately after the user inputs it into a textbox, or if your bot only uses a file for such information, decode when the program loads

[Skywing]

What happens if you implement this into your bot and the user decides that they want to log in and create an account on a private Battle.net server. Such as a PvPgn server? Often times these servers support "illegal" characters that the regular servers do not. Checking the account before they actually connect would really be a useless feature. The user should know what they can and can't use in an account.

An idea that could possibly save time when connecting could be:
 
   Decode cdkey's immediately after the user inputs it into a textbox, or if your bot only uses a file for such information, decode when the program loads

Except in the case of the chat gateway, all of the logic for dealing with the password in textural form is only in the client and not on the server, so that shouldn't matter for binary interface clients.

I would expect that the time spent doing key decoding is insignificant compared to many of the other operations you would do during a binary client logon.  If you are looking for ways to optimize you should really do some real profiling of your program first.

[Eric]

Decode cdkey's immediately after the user inputs it into a textbox, or if your bot only uses a file for such information, decode when the program loads

In most cases it's common practice to do as much as you can before you actually need to (providing that it's logical to do so) so that the only delay experienced is during the initial execution and/or connection, however the speed difference is often not very noticeable.  The most significant bottlenecks are going to be the version check and your latency with the server.

[MyndFyre]

First off, "iLLyz"?  And passwords can have any character you want in it.  They're sent in a 256bit hash so it doesn't matter what you have your password as

Uh... they're sent in a 160-bit hash (SHA-1).  The hash that's sent in SRP is hardly even related to the password, but the M1 value is 160-bit, as is the password hash sent with old-style logins.

[Mesiah / haiseM]

If you really wanted to find out what characters are acceptable or not, just have your client fully parse the return data from the account login packet. If there are illegal characters, it will return which one(s) are invalid... However, I don't think this works for the password string..

[UserLoser]

First off, "iLLyz"?  And passwords can have any character you want in it.  They're sent in a 256bit hash so it doesn't matter what you have your password as

Uh... they're sent in a 160-bit hash (SHA-1).  The hash that's sent in SRP is hardly even related to the password, but the M1 value is 160-bit, as is the password hash sent with old-style logins.

Duh...160.  Was thinking it was a 32 byte hash, oops.