LW3 – starting small

Alright, so I decided some time ago before all my posts were lost to nothingness that I was going to make LW3, complimentary to LW1&2, but entirely rebuilt from the ground up so that it had more security, a better UI, and all that fun stuff.   Well, it has come to my attention that I don’t like trying to build from the ground up anymore.  I have LW2, I used it for so long in fact that I forgot how to make a system like it again, with that much customization allowed, and efficient.  So, in lieu of that, I am going to start small with it.  Calling it more a templating system, or authorization system rather than start with the name LW3.  Doing that, I can build it in pieces rather than try and get a while system up and running quickly.  In reality of the entire scope of the LW3 project, it will be the authorization module, and the DB module already exists to use with it from when I was upgrading LW2.  That is the base of the LW system to begin with.  So it will have user authentication, then module authentication, then group authentication.  Not all at once, but building on it after the user authentication works and I start making it into LW3.

Now, why is it important for me to build a system from the ground up rather than using the base I already have?  Well, the base I have for authentication doesn’t work with the new secure (and Patent Pending I may add) authentication module that I am wanting.  This module will include both AES and RSA encryption to get things done.  It will make AKO (Army Knowledge Online) look like child’s play when viewed in the manner of security.  Yet…it will be simplified for user-requirements more so than AKO as well.  A user will only have one password.  They will never see their private key, the private key (CAC card for military users) will be stored in the DB.  Sure, sure, can’t that just be hacked.  Well, yes, hack the RSA encryption used for the private key…  I am sure it can be done, why not, eventually you can brute force anything.   But then, before you can even get to that step, you have to hack the 256bit RijnDael encryption using the user’s password+salt hash that is used to encrypt the RSA encryption.  Yes, it’s somewhat redundant, yes, the password for the two different encryptions are different. (yes, you can say ‘oh shit’ now, as you would never expect me to make it that easy, would you?)  Then, once you get past both of those (oh yes, forgot to mention that the password inputed by the user is hashed with a different salt and added to itself to get the final key of 1028bits, so that makes the brute forcing easy – you know you can skip trying any key between 1-1027bits ;] ) you will be able to impersonate the user and read their email.

Does all that sound like too much work for a hacker?  Why yes, yes it does.  It takes a hacker to know how to stop a hacker is the saying I believe, so good luck hacking my system fuckers. ;]

And that is just the rundown on part of the patent, the other part is dealing with files, and the emails that are sent via the public key, you see, everything else (other than the private key) is encrypted using a one-time key. (read: by god, by the time I hack just one email, and I won’t even know if it’s the one I am looking for, I will be old enough that I won’t care, or it will be my great-grandkids watching the screen to see when it’s done.)

This entry was posted in Liquid Web, Programming. Bookmark the permalink.