- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Yeah, that's quite the rookie mistake: they didn't do a case-sensitive length comparison.
Admin
This could be reduced to just: return inputLogin.Length == configFileLogin.Length && inputPassword.Length == configFilePassword.Length;
Admin
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.
Admin
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.
Admin
and who returns false?
Admin
Well no, because now people now know the username and password length. Just stick a 2 on the end and update configFilePassword accordingly.
Admin
The variable naming is spot on though
Admin
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.
Admin
What the code doesn't show, is that the password length has to contain 3 punctuation marks and 8+ alphanumeric characters.
Admin
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.
Admin
"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?
Admin
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!
Admin
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.
Admin
Nowhere, along the way, should you ever have a password/key in plain text.
That's the whole point of one-way functions.
Admin
It has to be in plain text SOMEWHERE even if it's just in the cable between your keyboard and computer I/O.
Admin
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.
Admin
This is why we have so many security issues. Passwords should be saved nowhere in plain text except for the wetware in your head.
Admin
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.
Admin
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.
Admin
Why do TDWTF articles always attract Captain Obvious and the Masters of the Redundant?
Admin
Let's see:
Supercalifragilisticexpialidocious...
Admin
"wetware in your head", implies someone somewhere has it on a postit near a keyboard
Admin
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.
Admin
To be fair, the password is 1024 characters deep, written really tiny on said postit.
Admin
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!
Admin
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.
Admin
Admin
"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.
Admin
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.
Admin
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.
Admin
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.
Admin
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?
Admin
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.
Admin
Wrong, try again. The context of the discussion:
- Someone says "don't store plaintext passwords, just hashes".
- 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.)
- The third random idiot comes along and explains how logins with hashed passwords work, which isn't remotely relevant.
Right back at you.Admin
At least in C#, Length yields an Int32 and GetHashCode yields an Int32, so they're obviously identical.