OK now that i'm using bcrypt the paranoia's went down a bit but went back up too

[133794m3r]

Ok, now since bcrypt has a string of salt that has to be provided or it'll just well expand one character all the way across for it. And well me being as paranoid as i am. How much of a security risk is it for me to do the following. As per another thread, i'm using 400 different nonces(as dbsheroh says it). With one static nonce which is the same for everyone. Upon registration the value is selected then is stored into the database in a table.

The thing that i'm wondering about is how much more risky it is to just use the same value for the salt i'm going to use for the encrypting of bcrypt. I figure that it shouldn't be too bad since it's still going to be there. But i was worried about the off chance that both people have the same password, and also have the same salt/nonce it'd make it a very tad bit easier to do. Also i'm still doing the old 24-64 random salt put at teh end of the password, with a 24 character salt at the front of it. And yes, i know how complex it is to do bcrypt with a setting of 2^7, but still i don't know what's going to come out in the future etc. And well paranoia is my best friend. That's why i chose to do 200 salts that are set via the values of said things stored in a script file with teh number corresponding it to for the look up being stored in the database in the username database. Since on my own machine here i was able to get ~190k per second where as bcrypt set at 07 i was able to get 62.2 per second. I realize that this alone along with teh shear amount of data that someone would have to brute force would make it nearly impossible to do. But as i said before, i am paranoid and shall always be such when it comes to security of my site. I try to make it a 1/(1*10^13) chance that anyone will be able to get the people's passwords or well in the in general also. And since computers are getting faster each moment, along with who knows what kind of setup a hacker could have it's always worrying me.

[Chris]

Since we talk about paranoia, isn't it that if someone has access to encrypted data they already have access to your server? Why woudn't they just modify the php code and get the password directly from html form when players login instead of cracking database?

[dsheroh]

The thing that i'm wondering about is how much more risky it is to just use the same value for the salt i'm going to use for the encrypting of bcrypt. I figure that it shouldn't be too bad since it's still going to be there. But i was worried about the off chance that both people have the same password, and also have the same salt/nonce it'd make it a very tad bit easier to do.

Maybe I'm misunderstanding you here, but bcrypt will always use 16 bytes of salt (which is why it repeats the salt if you provide something shorter).  If you generate a random 16-byte salt to pass to bcrypt when initially storing your passwords, that's 2^128 potential salts.  The odds of two users having the same salt, even if you have as many users as World of Warcraft, are so small as to not be worth worrying about, even if they do have the same nonce and same password.

And well paranoia is my best friend. That's why i chose to do 200 salts that are set via the values of said things stored in a script file with teh number corresponding it to for the look up being stored in the database in the username database.

My paranoia would never accept picking salts from a list of 200 possibilities instead of randomly generating fresh, unique salts as needed.  Using a list of pre-generated salts is where you're going to create a realistic chance of users sharing salts.  (1 in 200 rather than 1 in 2^128, to be exact.)  But I've already ranted to you about the lists, so I won't repeat myself. 

Since we talk about paranoia, isn't it that if someone has access to encrypted data they already have access to your server? Why woudn't they just modify the php code and get the password directly from html form when players login instead of cracking database?

Because they may have only compromised MySQL, but not gained command-line access, so downloading the database is all they can do.  Even if they do have command-line access, they may have cracked an account with read-only access to the PHP files, preventing them from changing it.

[133794m3r]

but wait... if you made a new and unique salt each time for bcrypt would it not then change how the encryption is set? And by doing that, wouldn't it make it so that the final encrypted piece of information is always different? And b/c of that wouldn't that make it so that each one's different? And also yes chris this is on the off chance that they only get 50% of the access.

Also hmm... so then how'd you add in the salt itself that's generated randomly inside of it? Since i jsut changed 1 character of the salt i was using it and it came out the same. Ok, it seems that it's not going to allow you to change more than 1-2 of it without it changing the entire final value(which is good) except well, this also means that i am and will be unabel to generate the salted value for the encryption on the fly and randomly. As each one will be different and thus as such will not work what so ever. :/ Now i'm going to try to figure out how to put a value inside of said string since it's currently using a $ $ for the salt value.

[gnoh]

With all this effort put into hashing passwords,   Are you going to have an SSL certificate for your game?  Why not implement one time passwords the list goes on, if you don't compromise at some point you'll end up having your game hosted on a server underground in a nuclear bunker with no network connection and switched off just in case your tempest shielding is not blocking out all the RF it may be emitting.

[133794m3r]

With all this effort put into hashing passwords,   Are you going to have an SSL certificate for your game?  Why not implement one time passwords the list goes on, if you don't compromise at some point you'll end up having your game hosted on a server underground in a nuclear bunker with no network connection and switched off just in case your tempest shielding is not blocking out all the RF it may be emitting.

SSL for logins? Why not? i was going to do that once i actually had a server setup though, i know there's a certain point where i just have to let it go and say ok i've done all that i can before the game becomes something that's nearly impossible to get players to play. So that's why i'm just trying to mget as close to that as possible.

[gnoh]

It costs money to have a SSL certificate,  is it worth the extra expense?

[133794m3r]

It costs money to have a SSL certificate,  is it worth the extra expense?

eventually once the gam'es up and running doing well? yes. Having a valid ssl certificate will make some players realize that their logins are secure. So it'll help a bit in getting some more players. When it launches i'm not going to use it b/c honestly during the launch it'll be about attempting to make sure that there's no bugs after i review my code a few times, and also testing how stable/fast the code is.