• (cs) in reply to abico
    abico:
    Someone You Know:
    Mark Bowytz:
    Anti-patterns and WTFs-a-plenty, it was hard to pick out just one example, but the following jumped out.

    Protip: using two metaphors that have nearly opposite meanings to describe the same thing can often render a sentence meaningless.

    Thanks for that, that bowytzed sentence was driving me nuts, too.

    ARRRGGH, matey.

    Geeze, I know I'm in trouble when I've been verbified! Time to head for the hills before the mob forms.

  • Jay (unregistered) in reply to Anonymous
    Anonymous:
    Daniel Pope:
    Challenge-response authentication requires unencrypted passwords. System security is often more important than password security.

    For example, my bank stores my password unencrypted. It does this so it can challenge me for individual characters from it rather than asking me to enter the whole password.

    I would strongly recommmend you bank somewhere else. If a bank wants to implement this kind of security they should do it with an additional piece of information, not your password. Lots of banks do this, but only the clueless ones do it with your actual password.

    That's right. They should ask you for a security question, like the name of your spouse or the high school you graduated from.

    As we all know, using personal information like that as a password is a very bad practice, because a hacker who knew you or was willing to do a little research about you could find those things out and guess your password. So you should always use a password which is a meaningless combination of letters, digits, and punctuation.

    But such passwords are hard to remember, so if you forget, there should be a way to recover or reset your password by using a security question like the name of your spouse or the high school you graduated from. These things can then function as a sort of alternative password, because knowing the answer to your security question is just as good as knowing your password.

    And of course, it would never occur to a hacker to research these things about you so that he could guess your security question. Just to make it even tougher on the hacker, the security question specifies exactly which piece of personal information is being used. If a hacker tried to guess your password, even if he supposed you might be using a piece of personal information, he wouldn't know whether you used your spouse's name or your dog's name or your favorite ice cream flavor or what. But with security questions, he knows exactly which piece of personal information to use.

  • Jay (unregistered) in reply to Anonymous
    Anonymous:
    Daniel Pope:
    Challenge-response authentication requires unencrypted passwords. System security is often more important than password security.

    For example, my bank stores my password unencrypted. It does this so it can challenge me for individual characters from it rather than asking me to enter the whole password.

    I would strongly recommmend you bank somewhere else. If a bank wants to implement this kind of security they should do it with an additional piece of information, not your password. Lots of banks do this, but only the clueless ones do it with your actual password.

    That's right. They should ask you for a security question, like the name of your spouse or the high school you graduated from.

    As we all know, using personal information like that as a password is a very bad practice, because a hacker who knew you or was willing to do a little research about you could find those things out and guess your password. So you should always use a password which is a meaningless combination of letters, digits, and punctuation.

    But such passwords are hard to remember, so if you forget, there should be a way to recover or reset your password by using a security question like the name of your spouse or the high school you graduated from. These things can then function as a sort of alternative password, because knowing the answer to your security question is just as good as knowing your password.

    And of course, it would never occur to a hacker to research these things about you so that he could guess your security question. Just to make it even tougher on the hacker, the security question specifies exactly which piece of personal information is being used. If a hacker tried to guess your password, even if he supposed you might be using a piece of personal information, he wouldn't know whether you used your spouse's name or your dog's name or your favorite ice cream flavor or what. But with security questions, he knows exactly which piece of personal information to use.

  • ullamcorper (unregistered) in reply to Maurits
    Maurits:
    Hmmm... maybe the database connection is set to NT Trusted Authentication, and [dbo].[Password] is:

    CREATE VIEW [Password] AS SELECT * FROM [Users] WHERE [Users].[Username] = USER_NAME()

    This begs the question - if the user is already authenticated, why ask them for a password?

    Maybe this is the password change screen.

    i loled.

    The only reason we ask our authenticated users for their password is to make them feel like they're contributing to the process.

    Plus, we have the upside of not having to actually check it, which saves us the aggravation of dealing with typos and caps-locked ebcaks who can never seem to get their password right, anyway.

  • Captain Obvious (unregistered) in reply to Daniel Pope
    Daniel Pope:
    Storing passwords unencrypted is not a WTF.

    You're right - storing passwords AT ALL is the WTF. C'mon people, store hashes of passwords, not passwords themselves, even if encrypted!

  • Jacob (unregistered)

    The WTF is actually 2 WTFs

    1. No username check means you can login with any password stored, not just your own (assuming the system does use a username and not just a single password)
    2. Passwords stored in plaintext (may or may not be an issue depending on where the access database is stored and how well secured it is)
  • Lego (unregistered) in reply to eric76
    eric76:
    Patrick:
    My brother once tried to break the accepted norm and create a login system without usernames. You log in with your password, that should be enough. After half an hour attempting to explain to him that usernames are good, it eventually boiled down to this: "You cannot create an account with this password because another account is already using it." "Oh. But they don't know what user id that password is for!" "The what? The username?" "Oh."
    I knew someone who modified the system on an old PDP-11 running RSTS/E to ignore the passwords. Instead, it associated each account with a record in the payroll file and when you were logging on, it would pull your record from the payroll file and ask you a random question about the record.

    Sometimes the question was pretty easy such as asking for the address. Sometimes the question was not so easy such as asking for what your year to date withholding is through the last payroll period.

    The result was that you pretty much needed a current copy of your records from the payroll file to be able to log onto the computer.

    It didn't take too long to revert to the canonical password approach.

    This is quite an interesting attempt at two factor authentication, years ahead of its time.

    --Lego

  • Nate (unregistered)
    Users password is in the db. If you can get into the db to get the users password, you don't need to know the users password.

    I work in a high school. Student's ID numbers are generally used as a unique identifier and a password for 90% of the student systems (computers, online grade access, etc.) Which is bad enough in and of itself. But I cried when I found out that a web programmer didn't bother to assign an autoincrement id field to the student table and had, in a live prom king/queen voting system, something that looked like <option value="123456">Student Name</option>, etc. where the value was the straight-up student ID.

    Of course, not that it mattered, since it used a javascript verification for logins that only checked to see if the id number was 6 digits long.

    In any case, you still want password encryption for the reason that people tend to reuse passwords. Most people aren't going to care if someone hacks Joe Blow's Bacon and Beastiality Discussion Forum's DB, but if they take the unencrypted password from that and use it to hit up your paypal, it suddenly becomes an issue.

  • (cs) in reply to Jay
    Jay:
    Anonymous:
    Daniel Pope:
    Challenge-response authentication requires unencrypted passwords. System security is often more important than password security.

    For example, my bank stores my password unencrypted. It does this so it can challenge me for individual characters from it rather than asking me to enter the whole password.

    I would strongly recommmend you bank somewhere else. If a bank wants to implement this kind of security they should do it with an additional piece of information, not your password. Lots of banks do this, but only the clueless ones do it with your actual password.

    That's right. They should ask you for a security question, like the name of your spouse or the high school you graduated from.

    As we all know, using personal information like that as a password is a very bad practice, because a hacker who knew you or was willing to do a little research about you could find those things out and guess your password. So you should always use a password which is a meaningless combination of letters, digits, and punctuation.

    But such passwords are hard to remember, so if you forget, there should be a way to recover or reset your password by using a security question like the name of your spouse or the high school you graduated from. These things can then function as a sort of alternative password, because knowing the answer to your security question is just as good as knowing your password.

    And of course, it would never occur to a hacker to research these things about you so that he could guess your security question. Just to make it even tougher on the hacker, the security question specifies exactly which piece of personal information is being used. If a hacker tried to guess your password, even if he supposed you might be using a piece of personal information, he wouldn't know whether you used your spouse's name or your dog's name or your favorite ice cream flavor or what. But with security questions, he knows exactly which piece of personal information to use.

    The security question doesn't necessarily indicate which piece of personal information to use. There nothing whatsoever preventing me from answering "what your dog's name" with my spouses name?

    Sure, almost nobody does that (I don't either, most of the time) but that doesn't mean I can't.

  • subnetmask255x4 (unregistered)

    The WTFs of this one:

    1. If the special _Password variable is set, then only that password can be used to login.
    2. Passwords in the database are stored in plain text.
    3. You can login with any username, possibly even a non-existent username, just as long as the password you entered matches one in the database.

    Special Bonus WTF: 4) If MDI.GetDataSet does not convert the database response of "zero rows" to Nothing, then any password you use will work, even if it doesn't match an entry in the database.

  • Mason Wheeler (unregistered) in reply to ContraCorners

    Huh? I do that all the time. I sorta figured everyone does. That's the only way to make it hacker-proof.

    CAPTCHA: transverbero. Recursive definition: something used to mutilate language and produce words such as "transverbero".

  • Franz Kafka (unregistered) in reply to ContraCorners
    ContraCorners:
    The security question doesn't necessarily indicate which piece of personal information to use. There nothing whatsoever preventing me from answering "what your dog's name" with my spouses name?

    Sure, almost nobody does that (I don't either, most of the time) but that doesn't mean I can't.

    I usually fill in the security questions all the same (matching the institution name) - it's a half assed attempt at 2 factor, so I treat it with contempt

  • Anonymouse (unregistered) in reply to Nick J

    What? The [ ] are not mandatory unless you're using a reserved word, just like isn't mandatory in MySQL etc.

  • Anonymouse (unregistered) in reply to Anonymouse
    Anonymouse:
    What? The [ ] are not mandatory unless you're using a reserved word, just like ` ` isn't mandatory in MySQL etc.
    Meant to respond to, forgot to use quote.
    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.

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

  • PublicLurker (unregistered) in reply to ContraCorners

    I hope you don't let your spouse know that you are using her name in place of the dog's. That would be a major WTF :-)

  • lagerdalek (unregistered) in reply to PublicLurker

    I don't understand why people are having trouble with this one.

    If String.IsNullOrEmpty(Password) Then Using dsUser As DataSet = MDI.GetDataSet( "SELECT * FROM [dbo].[Password] WHERE [Password] = " & _

    That's one WTF of a back door!

  • (cs) in reply to Jay
    Jay:
    Anyone who can access the database to steal the password can access the database, and therefore they're already in.

    No. What if they manage to steal a backup tape? What if they gain read-only access? Then they only have the hash of the password, not the actual password. Even if they do get write access to the database, they have to know the exact hashing method used (any salt used, hashing algorithm) before they can generate a hash that corresponds to a password they can use.

  • MP (unregistered) in reply to Daniel Pope
    Daniel Pope:
    PJ Volk:
    Daniel Pope:
    Storing passwords unencrypted is not a WTF.
    What's the worst that could happen...

    DoD testing, they sniff the network, and grep the system. If they find their password, you get a critical finding. Fix it, or take your box and go home.

    If you invent situations where it would be a ludicrous thing to do, then, tautologically, it's a ludicrous thing to do.
    MD5 is easy, but won't make you as famous. "Password information for 1.2 million users stolen from PopeBank" Now THAT will make you famous!
    Challenge-response authentication requires unencrypted passwords. System security is often more important than password security.

    For example, my bank stores my password unencrypted. It does this so it can challenge me for individual characters from it rather than asking me to enter the whole password.

    TRWTF is Daniel Pope's ideas about security.

  • (cs) in reply to MP
    MP:
    Daniel Pope:
    For example, my bank stores my password unencrypted. It does this so it can challenge me for individual characters from it rather than asking me to enter the whole password.

    TRWTF is Daniel Pope's ideas about security.

    Agreed. There's a problem on Project Euler about this very idea:

    http://projecteuler.net/index.php?section=problems&id=79

    For those too lazy to click the link, the idea is that an attacker has obtained a list of fifty successful login attempts where the login system uses Daniel Pope's idea. On the assumption that the characters are always in relative order left-to-right, the problem is to determine the full password.

    Obviously, this doesn't work if the login system uses random characters and allows duplicates, but it would still significantly narrow down the brute force search space.

    Now someone's going to tell me "if you have the plaintext login attempts you already have access to the target website/database/whatever". If you're about to say that, you're not thinking very hard.

  • PJ Volk (unregistered) in reply to Daniel Pope
    Daniel Pope:
    PJ Volk:
    Daniel Pope:
    Storing passwords unencrypted is not a WTF.
    What's the worst that could happen...

    DoD testing, they sniff the network, and grep the system. If they find their password, you get a critical finding. Fix it, or take your box and go home.

    If you invent situations where it would be a ludicrous thing to do, then, tautologically, it's a ludicrous thing to do.
    MD5 is easy, but won't make you as famous. "Password information for 1.2 million users stolen from PopeBank" Now THAT will make you famous!
    Challenge-response authentication requires unencrypted passwords. System security is often more important than password security.

    For example, my bank stores my password unencrypted. It does this so it can challenge me for individual characters from it rather than asking me to enter the whole password.

    I only wish I invented the situation. http://iase.disa.mil/stigs/stig/index.html - take your pick.

    I would bet your bank generates 5 challenges from your password (if it indeed does it), and hashes them. It reports the challenge, hashes it, and compares. My bank has several challenge questions. Testing seems to indicate it is case and punctuation insensitive. Doesn't mean it still cannot hash it (as long as it uses the sames rules when it stored it). The issue isn't so much protecting against the over-the-shoulder, or social engineering attack. Those will always be there. But the scope there is minimized because I have to compromise one account. Putting information in the clear blurs the inside and outside. To compromise one account from the inside is to compromise all the accounts. Of course, I can invent situations like the disgruntled employee, or like Office Space, or even the case where someone decided to use (and inadvertantly release) real data for test data. Not like none of those have ever happened.

  • (cs) in reply to PublicLurker
    PublicLurker:
    I hope you don't let your spouse know that you are using her name in place of the dog's. That would be a major WTF :-)
    That wouldn't be a problem. I don't even have a dog.
  • Nuns. No Sense of Humor. (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.
    Talk to to corporate (like a boss) Approve memos (like a boss) Lead a workshop (like a boss) Remember birthdays (like a boss) Direct workflow (like a boss) My own bathroom (like a boss) Micromanage (like a boss) Cruise the Intertubes (like a boss) Miss the punchline (like a boss) Say "I'd fire you" (like a boss) Look like a Jackass (like a boss)...
  • (cs)

    It is clear that this application doesn't have users. There is ONE password for the whole app, and anyone who knows that password is allowed to use the app.

  • Duhh (unregistered) in reply to Licky Lindsay
    Licky Lindsay:
    It is clear that this application doesn't *have* users. There is ONE password for the whole app, and anyone who knows that password is allowed to use the app.

    This. It's a table called "Password". Not "Passwords", "Password". It's clearly a single global password stored as a single row inside a DB table. No need for users.

  • (cs)
    It was written in VB6 and talked to an Access database in the back end and it worked.

    TRWTF is that the company spent money and time re-developing a working system.

    The 3rd party dev was happy to make the updates and rollout the now conforming application. Unfortunately, the availability and quality of support had gone downhill as of late and in order to save on costs, the application's source code was recalled to be maintained in-house.

    The 2nd WTF is that they brought it inhouse, assigning it to a programmer unfamiliar with the codebase and development history.

    The 3rd WTF is that this developer was known to be a novice in the target platform, and allowed him to work without any apparent oversight or review process until completion.

    The existence of the encryption WTF's, egregious as they are, are a predictable outcome of a thoroughly mismanaged development process.

  • (cs)

    Is it also a wtf that the function's parameters sender and e are never used?

  • Lee K-T (unregistered)

    Ok so the bloke looks at the source of a VB-Access soft and discovers that it's crappy. What did he expect from a VB-Access soft? Lol, this is a "My Cds and Dvds list" techno!

  • Lawrence (unregistered) in reply to Licky Lindsay
    Licky Lindsay:
    It is clear that this application doesn't *have* users. There is ONE password for the whole app, and anyone who knows that password is allowed to use the app.

    Damn, you beat me to it! I was reading through the comments and realised I was almost at the end and no one had figured this out. For this app, obviously they don't care who the user is providing they know the password, similar to those PIN-code office door locks.

    Obviously the app doesn't protect anything critical enough to require user audits, and so the use of clear text is fine too. It's a fairly safe assumption that anyone with access to the DB would know the common password.

    The real WTF is that "Rick P." has obviously never used the application he's attempting to ridicule.

  • Pete (unregistered) in reply to Grimoire

    My bank does this as well. So does my "Verified by Visa" pointless extra check when I try to buy things online.

    I can't think of a sensible way to do it that doesn't involve storing the password in cleartext in the DB. :(

  • (cs) in reply to Heron
    Heron:
    On the assumption that the characters are always in relative order left-to-right, the problem is to determine the full password.
    For the one site I know that uses this technique, the order is *not* relative order left-to-right.

    How much harder that makes life for the cracker, I'm not awake enough yet to work out.

  • (cs) in reply to JarFil
    JarFil:
    Daniel Pope:
    For example, my bank stores my password unencrypted. It does this so it can challenge me for individual characters from it rather than asking me to enter the whole password.

    They could keep salted MD5 hashes of the right answer for every possible challenge. That would be, how many? 65, 87 or something like that? I say it's not a big deal.

    In a well planned authentication chain, there is no way in which keeping cleartext passwords would increase security.

    That does not yet look well-planned to me - if you have the hashes, you should be able to brute-force the password, at least if the challenge is as simple as "what is the 5th letter?", because the number of possible answers is simply too small.

    PJ Volk:
    I would bet your bank generates 5 challenges from your password (if it indeed does it), and hashes them. It reports the challenge, hashes it, and compares. My bank has several challenge questions. Testing seems to indicate it is case and punctuation insensitive. Doesn't mean it still cannot hash it (as long as it uses the sames rules when it stored it).

    I am not sure if this is more secure. Anyhow, not storing plain text at least saves you from people seeing the password by accident.

  • SR (unregistered) in reply to BeKaY
    BeKaY:
    If String.IsNullOrEmpty(_Password) Then
    // Shennanigans

    FTFY

  • (cs) in reply to BentFranklin
    BentFranklin:
    Is it also a wtf that the function's parameters sender and e are never used?

    Those are standard parameters to any .NET event handler. Whether that is a WTF is left as an exercise to the reader.

  • London Developer (unregistered) in reply to Vollhorst
    Vollhorst:
    The problem is that the function does not check if the passwords begins with a Q or Z.

    Hahahahha!! Someone reads this site as much as me! ;o)

  • (cs) in reply to MP
    MP:
    TRWTF is Daniel Pope's ideas about security.

    No, it really does all depend.

    eg - on TDWTF what would it matter if the passwords were stored in plain text? If someone can get hold of Alex's database and see my password all they can do is post messages pretending to be me. Whoopdee doo.

    Now, I could be using the same password for other things, but that's my fault. I have no idea how TDWTF stores passwords. For all I know, the website may even store all login attempts in a plain text log file which can be downloaded by anyone.

    Thus - storing unencrypted passwords is not necessarily a WTF. In fact, several challenge response systems (eg CRAM-MD5) require un-hashed passwords to be stored. Is it safer to use CRAM-MD5 requiring un-hashed passwords to be stored but transmitting them hashed, or to use plain text authentication allowing hashed passwords to be stored, but transmitting them in the clear?

    Several banks in the UK do ask you 'what are the 3rd, 6th and 8th letters of your password'. I'm not saying whether this is good or bad, but I doubt whether all the possible combinations are hashed, so I think you can assume that they are storing the password either in the plain or encrypted using a reversible encryption (I would hope the latter).

    Their justification for this is that it is more likely that a user's PC will have a keylogger on it than that their database will be accessed without their knowledge (and by someone who knows the decryption key). Whether this is true or not (and whether this is an adequate defence against that) is up to you to decide.

    (FWIW, all the banks I use which use this system also have a hardware card reader that I have to use to authorise internet money transfers, so I'm not too worried about security anyway).

  • fw (unregistered)

    did someone say SQL injection? I know a song about that... http://xkcd.com/327/

    captcha: damnum

  • Patrick (unregistered) in reply to VB Master, VB Pasta
    VB Master:
    Dim _Password As String

    Public Sub New() ...snip... #if DEBUG _Password = "DebugModePassword" #endif End Sub

    I like this. But then why doesn't #if DEBUG and #else show up in the login function instead of using compiled code?

  • Patrick (unregistered) in reply to BentFranklin
    BentFranklin:
    Is it also a wtf that the function's parameters sender and e are never used?
    No. That's a standard .NET event handler, and those parameters are only there for the rare instances that they would actually be needed. I've had to work around code that didn't have them when I needed it. It's not nice.
  • (cs) in reply to KRex
    KRex:
    Daniel Pope:
    PJ Volk:
    Daniel Pope:
    Storing passwords unencrypted is not a WTF.
    What's the worst that could happen...

    DoD testing, they sniff the network, and grep the system. If they find their password, you get a critical finding. Fix it, or take your box and go home.

    If you invent situations where it would be a ludicrous thing to do, then, tautologically, it's a ludicrous thing to do.
    MD5 is easy, but won't make you as famous. "Password information for 1.2 million users stolen from PopeBank" Now THAT will make you famous!
    Challenge-response authentication requires unencrypted passwords. System security is often more important than password security.

    For example, my bank stores my password unencrypted. It does this so it can challenge me for individual characters from it rather than asking me to enter the whole password.

    Users password is in the db. If you can get into the db to get the users password, you don't need to know the users password.

    Yes, because no one ever uses the same passwords on different systems. By exposing their passwords in the event that a hacker gets access to your database, you are screwing them elsewhere as well. Good job.

  • Halbhorst (unregistered) in reply to Vollhorst
    The problem is that the function does not check if the passwords begins with a Q or Z.
    YMMD!
  • Jay (unregistered) in reply to ContraCorners
    ContraCorners:
    The security question doesn't necessarily indicate which piece of personal information to use. There nothing whatsoever preventing me from answering "what your dog's name" with my spouses name?

    Sure, almost nobody does that (I don't either, most of the time) but that doesn't mean I can't.

    Well, sure, if you don't use the system as intended, you avoid the gaping security hole.

    I don't answer these questions as asked any more either. I just give an alternative password, and give the same answer to all security questions from any given site.

    But I'm sure 99% of users, when asked, "What is your mother's maiden name?", give their mother's maiden name.

    Hey, let's face it, if you called people on the phone and said, "Hi, I'm with the security department at First National Bank, and we're doing a security audit. What is your password?", I'd bet that literally at least 30% would tell you.

  • (cs) in reply to pscs
    pscs:
    In fact, several challenge response systems (eg CRAM-MD5) require un-hashed passwords to be stored.

    I'm not a crypto geek, but I don't understand why this would ever be done. I would think it would be a simple enhancement to support storing them as a one-way hash. From what I read, CRAM-MD5 works like this:

    System -- string -> User System <- username digest(key=password, message=string) -- User

    Why not do this instead?

    System stores a one-way hash of the password using key syskey.

    System -- syskey+string -> User System <- username digest(key=hash(syskey,password), message=string) -- User

    We're no longer storing the password cleartext, nor is it reversible from the ciphertext, and it is still not transmitted in the clear.

  • AndyC (unregistered) in reply to Daniel Pope
    Daniel Pope:
    Challenge-response authentication requires unencrypted passwords.

    No it doesn't. Ever.

    If you're doing challenge/response by sending unencrypted passwords, you're doing it wrong.

  • One of ullamcorper's users (unregistered) in reply to ullamcorper
    ullamcorper:
    The only reason we ask our authenticated users for their password is to make them feel like they're contributing to the process.

    Plus, we have the upside of not having to actually check it, which saves us the aggravation of dealing with typos and caps-locked ebcaks who can never seem to get their password right, anyway.

    This morning i accidently entered a wrong password expecting an error message, but could login successfully. I even had all my usual permissions.

    It's obvious that your authentication software is completely broken and you didn't even perform basic testing on such a critical piece of software.

    I have informed the audit group and CCed your boss so that your incompetence and lazyness affect your bonus!

    CAPTCHA: eros (how did the CAPTCHA Software guess my password?)

  • NotaN00B (unregistered)

    Dear N00bs,

    The WTF is: the system will let you in if the entered password matches ANY password in the system!

    i.e. there is no [userid] = clause on the query.

  • Fister (unregistered) in reply to Dr.Dre
    Dr.Dre:
    I guess it's that there will always be a dataset returned (containing a table with probably no contents), so you'll always get an OK.

    That was my interpretation, too.

  • (cs)

    On a government project I once found a system whose PAM stack had been (it turned out inadvertently) muffed up in such a way that any password text was accepted as correct. Not any password on the system -- any password text at all. I found it when I was logging in, muffed my password, realized it just after I hit Enter, and was bemused to find I was nonetheless logged in successfully.

  • (cs) in reply to AndyC
    AndyC:
    Daniel Pope:
    Challenge-response authentication requires unencrypted passwords.

    No it doesn't. Ever.

    If you're doing challenge/response by sending unencrypted passwords, you're doing it wrong.

    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.

  • YukiHyou (unregistered) in reply to Duhh
    Duhh:
    Licky Lindsay:
    It is clear that this application doesn't *have* users. There is ONE password for the whole app, and anyone who knows that password is allowed to use the app.

    This. It's a table called "Password". Not "Passwords", "Password". It's clearly a single global password stored as a single row inside a DB table. No need for users.

    According to a number of Best Practices for Schema Design articles, the fact that it is a table infers that it contains more than one record. Thus, the name should be kept singular to prevent pluralization problems when coding access to the database.

    (CAPTCHA: ullamcorper - http://www.ullamcorper.com/ <- This?

  • Drak (unregistered)

    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.

    Perhaps it's more a kind of 'Verify that you really want to do this (by re-entering the password)' idea?

    Anyway, for all we know _Password may store the password entered at login, so it doesn't have to de database lookups to match this weird verification-like dialog.

Leave a comment on “Encryption Misinformation”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article