New answers tagged

1

I always encourage a cleanup of the usings at the top of the page, so when I look at the code I know roughly what Im going to be getting into.


1

The conversions to bit-strings, then ints and back to strings are unnecessary. m and k are bytes, so the elements (e.g., m[0] or k[i]) are already integers in the range 0-255; bitwise operators can be applied to the elements directly. I think routines in the Crypto library return strings, so the encrypt() return value might need to be encoded before using ...


4

There are lots of ways to improve this hard-to-read code but all of them are unimportant compared to the fact that this is massively insecure against common attacks. You are implementing a component of a security system; you need to build a threat model and understand what you are doing. Implementing a security system is not a beginner task! An important ...


1

Remove unnecessary comments: var random = Factory.Random(); //Generates new Random() from Factory class. It's obvious if you read the code. It's ok to break those lines availableCharacters = characters .Where(c => !output.Substring((position - rule) + 1, rule - 1).Contains(c)) .Aggregate(availableCharacters, (current, c) => (...


2

Upon registration, don't send the real user password to the server, use Argon2 hash of the real password instead. In my understanding, it should be pretty hard for a server to infer the real password based on Argon2 hash and without salt. It makes it harder, by a constant factor. If the password is weak, it can still be found. Password based authentication ...


5

There are a few things wrong security wise before we even get to the parameters. private char[] password; Storing the plain text password in an instance field makes it discoverable from memory dumps for a considerably long time. There is no need for the field to be an instance field since it is only used in the hash method. public void hash(String ...


3

a few comments, from high to low-level: Usability users are generally pretty terrible with passwords! having them "lose" all their data if they forget their password often isn't something they expect. i.e. they just want to do a "password reset" and get access to everything again. I know this is at odds with what you (and lots of similar designs) are ...


0

in addition to what has already been said, I'd suggest not using clientExists at all. just have a UNIQUE constraint on clientName, siteName and let the database enforce this for you. the reason is that your current code is both doing more work than is needed (the check for existence) as well not enough (the gap between the existence check and inserting a ...


Top 50 recent answers are included