• 0 Posts
  • 107 Comments
Joined 9 months ago
cake
Cake day: March 21st, 2024

help-circle
  • Sure just if fully given in this way it’s basically the same as an 11 character password.

    Only of the attacker knows whether it’s a password or phrase. I’d argue that passwords are far more common and that’s what a cracker would focus on first.

    should be resistant to attacks even if there is perfect knowledge of how it was generated

    As far as I know there still is no way to create actual randomness. You’ll still have some pseudo-random number generator and a hopefully unguessable seed. If you have “perfect knowledge” about that, cracking the password is almost trivial.












  • If you go back to my example, you’ll notice there is a UserUniqueValidator, which is meant to check for existence of a user.

    Oops, right, I just glanced over the code and obviously missed the text and code had different class names. Another smell in my opinion, choosing class names that only differ in the middle. Easily missed and confusion caused.

    I don’t think our opinions are too far off though. You’re just scaling the validation logic to realistic levels and I warn that in practice coders extrapolate too quickly and too often, which results in too much generic code which is naturally harder to understand and maintain than specific code.


  • I would argue that the validate routines be their own classes; ie UserInputValidator, UserPasswordValidator, etc.

    I wouldn’t. Not from this example anyway. YAGNI is an important paradigm and introducing plenty of classes upfront to implement trivial checks is overengineering typical for Java and the reason I don’t like it.

    Edit: Your naming convention isn’t the best either. I’d expect UserInputValidator to validate user input, maybe sanitize it for a database query, but not necessarily an existence check as in the example.