Comment by Jan Vladimir Mostert on "What to do when you can't write unit tests, but you want to ship a reliable product?"

Write your software as modular as possible, that way when you make changes, you only affect one part of the system. So if you need to be able to have users log in, have an Account module handling password resets, authentication, authorisation, etc. If you need Email, build an email module that handles all email in the system, etc.

Further, build APIs for everything and do everything via APIs - I usually build RESTful JSON APIs with Create, Read, Update, Delete, List and Search.

Java uses UUID version 4 which has 122 bits of randomness built into the 128 bit UUID which is not guessable, multiply the 122 bits by 4 since I'm concatenating them + stripping dashes and then also take into account that if you send an incorrect UUID for a certain username, all UUIDs for that username is invalidated (although I only allow one UUID per username to be active at any time), if you try multiple times, your IP gets blocked.

So in practice, if you guess the UUID incorrectly the first time, you invalidate all other valid UUIDs in any case, if you try a second and third time or tamper in any way with some of the other data in the cookie (you won't have any success in any case since the UUID has already been invalidated during the first attempt), your IP gets blacklisted and you will simply get the same response (login: true, access: false) over and over until your IP is removed from the blacklist again.

All of this is going via SSL, so only you, once you have logged in, will be able to see the UUID, any attempt to tamper with the UUID blocks your IP and any attempt to guess someone's UUID will log them out invalidating the UUID followed by blacklisting your IP if you continue trying. Guessing the concatenated UUID is like guessing a 64 character password which is randomised by Java every time you log in of which you only have one shot.

To me the Java implementation sounds pretty secure, I can't speak for other languages though. Have a look here, as you can see in the source code snippet, Java uses SecureRandom to generate the random bits: stackoverflow.com/questions/7532807/are-java-rand…

Maybe I'll start a topic on GUID security, then we can peek into which languages do it securely and which ones don't.

GUID's aren't cryptographicly secure and shouldn't be used as security tokens. security.stackexchange.com/questions/890/are-guid…

I send a GUIDx4 tokens (4 GUIDs concatenated together) with every request automatically - the GUID token is generated once you login and kept in a secure-http-only cookie. So every request to the API automatically includes the cookie with the token and then inside the API logic I simply extract the token, check if that token is valid against a Redis database, if not, reject the request and send back an access denied (in which case the frontend will popup a login dialog).

Since the Cookie is set on the API's domain instead of the frontend domain as well as HTTP-only flags, JavaScript can't tamper with the Cookie or even read it, once you do an AJAX post, the browser automatically includes it as part of the post, so the browser itself is the only thing that can read the cookie. Without the cookie containing a valid GUID / token, you can't interact with the API, it will just respond with {access: false, login: true}

I typically have to implement CORS on the API as my AJAX requests are coming from a different domain than the API is sitting, see this post for more info on the security aspects: security.stackexchange.com/questions/84860/how-to…

Search Hashnode