• Ulysses (unregistered)

    Yeah, that's quite the rookie mistake: they didn't do a case-sensitive length comparison.

  • Paweł Lis (unregistered)

    This could be reduced to just: return inputLogin.Length == configFileLogin.Length && inputPassword.Length == configFilePassword.Length;

  • Tom (unregistered)

    Does solve a lot of issues: caps lock, other keyboard layouts and so on... still a shame that the file containing the login information was not name password.txt... otherwise a very user friendly solution.

  • Quite (unregistered)

    Where's the problem? You've got to guess the length of both the username and the password correctly. What's the chance of doing that more than once? Boss was just lucky, and the long-term fix is that he needs to be assigned a username or password of a different length. Simples.

  • bvs23bkv33 (unregistered)

    and who returns false?

  • James (unregistered) in reply to Quite

    Well no, because now people now know the username and password length. Just stick a 2 on the end and update configFilePassword accordingly.

  • anonymous (unregistered)

    The variable naming is spot on though

  • Chronomium (unregistered)

    This reminds me of an IRC server (like five years ago) that would give ops to anyone with a six-char nick. I think it was some sort of in-joke.

  • GWO (unregistered)

    What the code doesn't show, is that the password length has to contain 3 punctuation marks and 8+ alphanumeric characters.

  • Jeff Dege (unregistered)

    You know, I did something very similar to this, stubbing out the back end of a login form.

    I accepted any password that had an even number of characters and rejected any odd.

    The idea was so that the front-end folks could test that they were properly handling both success and failure, without their having to wait for the password authentication module to be done.

    We did, however, remember to replace the stub with one that called the password authentication module, before we shipped.

  • fragile (unregistered)

    "It wasn’t the most secure thing on Earth"

    Is that a general statement about the application, or storing passwords in a config file?

    Don't most web applications store a password in a config file, if not admin, then something even worse like database passwords, encryption keys, and salts?

    Isn't the only alternative is storing in a env, which reads a temporary password from something like Hashicorp Vault or AWS KMS?

    Isn't doing that for a salt, and keeping a diary of those really hard to do?

  • eric bloedow (unregistered)

    reminds me of an old "program puzzle" in a book: a program was set up for "good guy" passwords (any number divisible by 3) and "bad guy" passwords (any number divisible by 4), but the villain had tried to change it to reject ALL passwords. BUT a "bug" in the program made it still accept numbers that were divisible by 3 AND 4!

  • Zenith (unregistered) in reply to fragile

    Somewhere along the way, you have to have a password/key in plain text. Doesn't matter if it's in a configuration file, an environment variable, a database, or some sort of managed solution that's really just another layer that has its password/key in plain text somewhere. It's just a matter of how many hoops you want to have to jump through to make your application run.

  • Jeff Dege (unregistered) in reply to Zenith

    Nowhere, along the way, should you ever have a password/key in plain text.

    That's the whole point of one-way functions.

  • jgh (unregistered)

    It has to be in plain text SOMEWHERE even if it's just in the cable between your keyboard and computer I/O.

  • Avium (unregistered) in reply to jgh

    Sure. But that's only in-flight. There should be no permanent storage of a password in plain text. Store the correct answer of the one way hash and compare the incoming hash.

    Of course, that could be too much effort depending on what is being 'secured' by the password.

  • (nodebb)

    This is why we have so many security issues. Passwords should be saved nowhere in plain text except for the wetware in your head.

  • foxyshadis (unregistered) in reply to Jeff Dege

    If you authenticate to the remote server using a hashed value, then the hash is a plain-text password, for all intents and purposes, just a difficult-to-bruteforce one.

  • I Am A Robot (unregistered)

    So Julia didn't read the email about admin access being opened to everyone in the IT dept? I'm assuming the user names have some structure and the length of the IT ones would be different to any other dept.

  • siciac (unregistered)

    Why do TDWTF articles always attract Captain Obvious and the Masters of the Redundant?

  • (nodebb)

    Let's see:

    Supercalifragilisticexpialidocious...

  • snoofle (unregistered) in reply to KattMan

    "wetware in your head", implies someone somewhere has it on a postit near a keyboard

  • bobcat (unregistered) in reply to jgh

    REALLY secure locations will have encrypted input devices too. Keyboards, keypads, RFID dongles and biometric scanners. Such that a snooper widget plugged into the line gets nothing but garbage and possibly the occasional plaintext insult to a hacker's mother.

  • bobcat (unregistered) in reply to snoofle

    To be fair, the password is 1024 characters deep, written really tiny on said postit.

  • RichP (unregistered)

    But I tested this code and proved it works. I set my password to "hunter1" and when I tried to log in using "hunter" the system didn't let me in!

  • nasch (unregistered)

    If you authenticate to the remote server using a hashed value, then the hash is a plain-text password, for all intents and purposes, just a difficult-to-bruteforce one.

    You send the plain text password (via a secure channel), then the server hashes it and checks it against the stored hash. So if you get hold of the stored hashed password that does you no good at all for trying to log in to the system, because you cannot derive the plain text password from the hashed value.

  • I'm not a robot (unregistered) in reply to nasch
    You send the plain text password
    ... which requires that you HAVE the plain text password, which is the point under discussion, which you would know if you could be bothered to actually read the thread and not cream yourself at the chance to show off how much you know about trivial basic concepts.
  • tlhonmey (unregistered) in reply to Zenith

    "Somewhere along the way, you have to have a password/key in plain text. Doesn't matter if it's in a configuration file, an environment variable, a database, or some sort of managed solution that's really just another layer that has its password/key in plain text somewhere. It's just a matter of how many hoops you want to have to jump through to make your application run."

    Nah, you just have the final level of password storage be on a machine that keeps it all in encrypted, volatile memory and then make sure you have a really good UPS.

  • Decius (unregistered) in reply to Zenith

    It's entirely possible to never have a password stored as plain text. The auth module takes the supplied credential, salts and hashes it according to one scheme, and compares that to the first stored hash, then salts and hashes the supplied credential using a different hash scheme and compares it to a second stored hash; if both checks pass, the auth module reports that it passed.

    With that system, you can't even say "the hash is the plaintext password", although it comes with its own problems and doesn't provide any better security unless both hashes are bad in very specific ways that suggest you should not use them at all.

  • Koen van Dratel (unregistered) in reply to I'm not a robot

    Most of the underlying concepts are basic nowadays but I would be interested (and amused) to hear your arguments for why they should be considered trivial. Of the several points under discussion the one that Nasch clarifies is that - given that a password has to be send server - the choice is to either compare the hash of the password with a stored hash of the password or to compare the password with the stored password. In the former case, it is harder for another party to retrieve a matching password.

  • anonymous (unregistered) in reply to Paweł Lis

    Not necessarily. The function doesn't return false right after the conditional statement so it's possible that it does something else before returning if the password is incorrect.

  • Shufflepants (unregistered)

    Maybe it is actually secure but they require you to choose your password, convert that string to a number, and then enter that many zeros as your password?

  • doubting_poster (unregistered) in reply to I'm not a robot

    No it does not. Sorry to topple you from your pedestal, but the point under discussion was never to store the plaintext password anywhere permanent. If you send the plain text password from the user's login via a secure channel, that is not permanent storage. Reading fail on your behalf.

  • I'm not a robot (unregistered) in reply to doubting_poster

    Wrong, try again. The context of the discussion:

    1. Someone says "don't store plaintext passwords, just hashes".
    2. Someone else says "if you can log in with just a hash, then the hash may as well be the password". Obviously this is referring to passwords that the application needs to access a database server or some other service, where you need the actual password, not just a hash. (Yes, it's possible to have the application prompt for the password at startup rather than storing it permanently, and that might be preferable in a high-security environment, but often you want the application to be able to start without human interaction, and in that case you do need to store the password somewhere.)
    3. The third random idiot comes along and explains how logins with hashed passwords work, which isn't remotely relevant.
    Reading fail on your behalf.
    Right back at you.
  • Peter Wolff (unregistered)

    At least in C#, Length yields an Int32 and GetHashCode yields an Int32, so they're obviously identical.

Leave a comment on “Secure Login”

Log In or post as a guest

Replying to comment #489397:

« Return to Article