• AndyC (unregistered) in reply to beltorak
    beltorak:
    Not entirely correct: one of the weaknesses of CRAM-MD5 is that it " [c]arries server requirement for storage of reversibly encrypted passwords." I liked the suggestion on another post of storing (and subsequently using) a hash of the password instead. I think the extension (RFC 2195) does something similar.

    But that's clearly retarded and thus not worthy of consideration. Obviously if you use a stupid CRAM then it might rely on reversible encryption. The solution is to use a decent authentication method.

  • Zastai (unregistered) in reply to Patrick
    Patrick:
    Occasional Reader:
    I'm struggling to see a major WTF here - there are a few minor ones - such as testing a variable which you assume should have been populated in there somewhere (_Password), assuming that there is only 1 record in the password table (or worse are you just checking that the user has selected one of the passwords in that table), storing passwords in plain text but to be honest they're not completely evil. Plain text passwords are fine for certain non-critical applications.

    Is there something more nefarious that I've completely missed here?

    It's all of them put together.

    • The password is not encrypted, even though there is a simple ROT13 and perfectly good AES encryption system just a function call away.
    • The username is not implemented at all, meaning that any username will log in as long as a password matches.
    • Any password. As long as it's in there.
    • If two people have the same password, someone will log in to the wrong account and be unable to access their own.
    • The condition is that the dataset has been assigned a value, even though "zero rows" and "two rows" and so on are still valid, resulting in a successful login every time.
    • Even if the login could be unsuccessful, the password may still be accepted by comparing it to a variable that gets set somewhere unseen.

    captcha: gravis. this is a gravisituation forsecurity.

    Actually, since this is a Click handler on a dialog's OK button, I rather figure this to be a UserPasswordCheck form, instantiated with user name & current correct password (the _Password variable). So as long as a user has a current password, the code works; a user with no password set can use any password that's in the database (and this may or may not be an edge case, depending on whether the system lets you set an empty password at all).

    The password's still in plaintext, and the above behaviour is odd to say the least, but to me it's not exactly a huge WTF - at least not without more of the code's context.

  • John Muller (unregistered) in reply to Joe
    Joe:
    For what it's worth, the Citadel-86 BBS software back in the 80s and early 90s had usernames (obviously), passwords (obviously), but you only logged in with a password (not-so-obviously). While there was functionality to lockout a session after X failed login attempts, it was still prone to brute-forcing...

    ...or the inevitable creation of your account, only to be told "this password is already in use". It is? Hot damn!

    Aeons ago, back when I was in middle school, I met someone else in my school who also owned a computer with a modem.

    He gave me the number for his favorite BBS, and that night I tried it for the first time.

    Username "James Bond" (hey, I was 12, and a big fan) Password ">007<" (symbols to be extra secure)

    and it worked... but I already had private mails?

    Turns out, the guy at my school not only used the same online name as I usually did (which I didn't know beforehand, I didn't get his username, just the phone #), he also used the EXACT SAME PASSWORD.

    How's that for amazingly weird?

  • hoodaticus (unregistered)

    This is actually a feature! This way, your password will work even if you forget your username!

  • Bryan W (unregistered)

    I don't use the dataset type because datatables are so much easier, but I believe that anytime you get a result set from the database, whether there are 0 rows or 1000, it will not be "nothing".

    So this line will accept every password that anybody might possibly type in:

    If dsUser IsNot Nothing Then
Me.DialogResult = Windows.Forms.DialogResult.OK
  • (cs) in reply to Drak
    Drak:
    The fact that this function shows a dialog window saying 'OK' if the password is correct leads me to assume it's not a login box.
    Except that it doesn't. If the password matches, the current dialog box's result is set to OK, meaning that the dialog box closes and the rest of the application continues. If the password doesn't match it pops up a message box indicating this and resets the password field so they can have another go.
  • (cs) in reply to Nick J
    Nick J:
    I'm no VB expert, but these are my thoughts/assumptions:

    Utils.ConvertToDBString cleans the input to prevent SQL Injection

    _password may contain a programmer back-door password, so if it's present in the code, it won't even use the database at all and it's only possible to use that one password.

    There's no checking of usernames at all.

    ^^^ This.

    Nick J:
    Microsoft dialect of SQL is so ugly, all those []'s all over the place. Horrible.

    And this too. Don't get me wrong. I love VB, but goddamit, of all things MS dialect of SQL is hideous beyond description.

  • ClaudeSuck.de (unregistered) in reply to Occasional Reader
    Occasional Reader:
    I'm struggling to see a major WTF here - there are a few minor ones - such as testing a variable which you assume should have been populated in there somewhere (_Password), assuming that there is only 1 record in the password table (or worse are you just checking that the user has selected one of the passwords in that table), storing passwords in plain text but to be honest they're not completely evil. Plain text passwords are fine for certain non-critical applications.

    Is there something more nefarious that I've completely missed here?

    For example that the application already knows the password (_Password) before the user clicks on OK. Only if it couldn't find a _Password it looks in the database if it can find whatever string you entered.

  • G (unregistered) in reply to Anonymous
    Anonymous:
    This is a usability feature. If anyone forgets their password they'll still be able to log in to the system with "password" because we all know that at least one idiot user will have chosen that as their actual pass ("root", "admin", "god" and "love" are also acceptable substitutes). This is actually a very clever recovery technique.

    If the company has programming staff "Gandalf" will probably work too...

  • Mikey Pulau (unregistered) in reply to Daniel Pope

    I pray to God, Allah, Buddha, Bob and The Flying Spaghetti Monster that you are not a developer, mister Daniel Pope. I've met people like you before, one of them had worked for the national bank of a small country and was now working for a financial company in London. Just like you, he was a security expert. Challenge response authentication DOES NOT require unencrypted passwords. In fact, unencrypted passwords are only one type of challenge response authentication, and it's the most insecure. I supposed all those crypto people working on secure authentication protocols are just fools and the zero-knowledge password proofs they have invented/implemented are basically the same to you as invisible pink unicorns.

    For example, your bank exposes you to unnecessary risks. Asking for individual characters either weakens your password's resistance to brute force, exposes itself (and you) to denial of service attacks or just provides you a false sense of security. I would love it if you could tell me the name of your bank... and maybe your username too...

Leave a comment on “Encryption Misinformation”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article