On Sunday, December 1, 2002, at 03:49 PM, Patrick Dughi wrote: > Sounds like you're making software licence certificates. This > shouldn't be too hard, the only trick is to make sure that no one else > can > make their own. > Since it contains at least some known information, decrypting > won't be very difficult. If someone gets 2 or 3 of them on the same > character & race, it probably wouldn't take more than 15 minutes to > 'decode' your system and forge their own certificate. Very similar, yes. However, the setup only gives the person 2 of the 3 pieces of information. Unless they figure out what number each of the non-standard races are, they can't get that third piece, there is some measure of security. Also these passwords aren't going to be just passed around. Basically, I am restricting these races because I dont want them played unless the person has proven that they are good role-players and can handle the race. For example, the vampire race, while seemingly becoming more common on fantasy MUD's with little concern to playability balance, have severe limitations and great powers on my MUD. Their innate strength and abilities make them extremely potent, but because they can be killed permanently (They are one of the few races I have that if you die a certain way with them, it will also delete the character) they have the potential to be mishandled by a poor player. I am not as concerned with characters getting enough of them to crack the code....I may even have a fourth variable...one that I set myself on both the MUD and the codes, so that it never really is breakable. > I'd recommend just storing the information on the player > structure > somehow, and making it transferable if that's necessary. If you > _need_ to > have a password system, I'd just store the certificate data in a > seperate > file, load it at boot time, and auto-generate passwords which index the > necessary data (character name, race, expiry). Unfortunately, with the system I want (having the password entered during character creation) that isn't strictly possible, since there will be a new structure made. And 'linking' player structures together isn't something I feel an overwhelming desire to implement. Having a database of passwords, which would be easier, also could be more problematic, since I need to go in, edit the file, and then make the MUD learn the password every time. If it had a self-validating system where all I needed to do was generate it and then the MUD verified if it was valid and then implemented it, would be simpler and give me less headache. > Still, it's not like it's a difficult thing. Just make up an > encryption method that takes those three values, and spits out a > string. > I recommend you make the algorithm you use rely on look-ahead or > look-behind tricks though; using caesar's cipher (ROT13, etc) is too > simple and will quickly fall apart. I actually found some code online talking about this as well as an article on it. Hopefully, with some free time coming up, I can sit down and pour over it, and come up with some ideas. My only concern is making the code from being too long. Last thing I need is a 40 digit code. However, that does add an element of security to the whole thing. > I've seen some that just XOR their entire file, or use a static > internal keyword to encrypt and decrypt the data (and some even have > shell > scripts that create the intital file on install with the word in > plaintext!!!) I have heard about this method a lot in my searches of the subject. But as of yet, never seen it. How does it work? What bits are XOR with what? Its been far too long since I have done complex logic circuits. ;) -- Now with PGP Encryption! Ask for your public key TODAY! -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | | Newbie List: http://groups.yahoo.com/group/circle-newbies/ | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT