Nice Coder

  • Content count

  • Joined

  • Last visited

Community Reputation

366 Neutral

About Nice Coder

  • Rank
  1. Quote:Original post by SymLinked Hello everyone! I've been playing around with our login system (for our hobby project) again now. I coded it a while back. We used RSA to pass the AES key, but it was a pain to get working (probably because of my inexperience). A ton of problems I'm not going to describe here. Anyway, because of these issues and the fact that SSL does all that and is tested, I'm considering making the registration by HTTP/SSL and using hashes to pass the password upon login ingame. But I'm getting doubts, as usual. -_- Are hashes (say, 512 bit) really "secure"? I was thinking of hashing the password with some random number and sending it off to the server. I've read Hplus (I think it was his!) excellent article on this, but I felt some of this was missing and I had more questions than answers afterwards. I do realize dictionaries of all possible combinations from a hash can be made, but it would take very long. Wouldn't it? What does online games use, are there any whitepapers or articles on this? Sorry for the rambling and thanks for any suggestions you can give me. A 512 bit hash is rather secure. (average brute force attempt would have to go through 2^511 plaintexts to find a matching password.), assuming it is an appropriate hash. (ie. sha256, etc.) Just make sure to include salt, preferably some given and some non-given salt. to demonstate, assuming 512 bits given, 8 bits non-given salt, you would generate your final value with something similar to this: sha(nongivensalt + givensalt + sha(password)) non-given salt slows down all accesses, so it should be kept small (ie. 4 bits, 8 bits, etc.). Mainly because you need to brute force half that many combinations before you will find a match. (which is still pretty fast for you, but makes it 2^x times slower for an attacker to brute force). Similarly the given salt makes it very hard to build a rainbow table type attack (which is one of the nicest ways to crack password hashes). Prehashing the password also stops somebody from only needing to check, for example, alphanumeric characters to crack a password. Overall with 4 bits of non-given salt, and 512 bits given salt, and with a 512 bit hash function, it should take approximatly 2^(4+511-1) or 2^515 to put that in perspective, 2^515 is roughtly: 10,726,246,343,954,077,679,659,219,998,564,676,901,983,492,656,473,914,702,178,849,154,977,411,224,058,837 5,814,414,994,385,335,227,421,520,254,865,491,888,406,830,031,062,495,572,559,571,469,192,048,672,768. As per sending it over the wire, you could create 2^x hashes from the normal given hash and password, and then rehash that with a second transport salt. When you send them to the server, the server checks them against the one it has (similarly hashes with the same transport salt) Take x to be 4, you need to send 16 hashes per logon attempt. (probably all at the same time.) Nice enough?
  2. A quick regex hand...

    (?<Token>%(.*?)%) Try that. (the ? makes it match first, basically)
  3. create a solver, get $2,000,000

    i would be very interested in setting up a team to solve this. (sharing rewards equally). Anybody interested? [Edited by - Nice Coder on November 24, 2009 3:30:59 AM]
  4. [web] PHP, sessions and security

    Quote:Original post by Sander Quote:Oh, use the md5 or sha1 function on the password before storing it in the database I recommend something tougher. MD5 hashes for (short) passwords are easily recoverable with the help of rainbow tables. Take a look at the hash functions to see what's available. MD5's good enough for e.g. a blog or a forum which are not interesting for a hacker to steal and run through rainbow tables, but you should push for the best when dealing with e-commerce or other sensitive (private) data. Unsalted md5 can be recovered quickly through rainbowtables, usually within a few minutes. (maybe hours) However, store a salt value, and use it. ie. caluclate sha1(salt ^ md5(password)) with a 128 bit salt. You store the salt as an additional field. This is surprisingly secure against attack. (brute force/dictionary attacks are the ony things that can put a dent in, however any precomputed attack (time/memory tradeoffs like rainbowtables, ktables, etc.) are foiled.) Also, you could create a derived key from the password and username (ie. sha1(md5(username) ^ md5(password)))), and encrypt your sensitive data with that when needed. (if you have anything that sensitive).
  5. a problem with desynching

    timestamping is good for stopping the really wierd and wodnerfull effects of lag. Each computer just needs to send messages to each other to discover their ping, and then work out the time of the start of the session. (The network game) From there you use the time since the start of the session as a timestamp to timestamp events. This should save you some heartache when your game starts freaking out and you can't figure out why. HTH
  6. peltier sandwich, with watercooling?
  7. lmhash problems

    i'm not particularly adapt with the des cypher, is there any way to set it so that pydes will work for this limited application? (i can't seem to find any other python des implmentations).
  8. hey, i'm building a little lmhash module (don't worry about why) The problem is that the spec seems to be contradictory. i'm supposed to split the password into two 7 byte halves. (which would then require a block size of 7) I then use it as a key to encrypt “KGS!@#$%”. The problem is that that is 8 bytes long. (which then requres a block size of 8 bytes). This is weird. I'm using python 2.5 with pydes on windows xp.
  9. at the moment i'm building a simple rainbowtables implementation for a small project. I'm having a little bit of trouble with the reduction function. The reduction function takes an integer (the previous hash value), and returns a new password (random string of given length, and given characterset). at the moment i have this: charset = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" minlength = 2 maxlength = 3 #reduce the input number into a valid password. (given by charset, minlength and maxlength) def redu(inpnum): inpnum %= len(charset) ** maxlength - len(charset) ** minlength inp = inpnum + len(charset) ** minlength #create the right offset ch = "" while 1: ch = charset[inp % len(charset)] + ch inp /= len(charset) if inp == 0: break return ch This, however doesn't work. (won't return anything starting with A, for example). I'm looking for it to return, for example f(0) = "AAA" f(1) = "AAB" f(2) = "AAC", etc. I'm currently think of using the "div-mod" type of method. ie. representing the number as x * charlen^0 + y * charlen^1, etc. For example, for upperlength characters, using the input 3432. 3433 = 1 * 26^0 + 2 * 26^1 + 5 * 26^2 which then means that it should be equal to EBA, iirc? Any ideas on how to get it to work properly? [Edited by - Nice Coder on February 19, 2007 1:15:05 AM]
  10. making USB-portable windows applications?

    python requires python25.dll which you can find in C:\windows\system32 Copy that into your python25 directory and copy that to your flash drive and it should (fingers crossed) work. i've tried it with the cli version of python, i'm not sure about idle or pygame, however.
  11. Bitstream packet null?

    i'm not particularly good at this, but why are you using a character, rather then a string? unsigned char message;
  12. Idle computer needs work.

    i've got a couple servers that would love to run on that box :) And hos always has more then enough room for another coder (hence solving both of your problems :D) Pm me?
  13. International keyboard hell!

    :) :D
  14. International keyboard hell!

    i'm using winxp (iirc professional), on this computer.