• Kevin (unregistered) in reply to John Cowan
    Anonymous:
    What's wrong with forbidding different users from having the same password?  I know of at least one system where no password may ever be even reused, whether it was you or another user that formerly employed it.


    It doesn't make a system that much more secure. A privileged account should have a password sufficiently random that another user is unlikely to have the same one. Possible, but rare.

    It actually makes the system less secure. If you realise someone else has or had that password it is no longer secret. A quick run through LDAP can see if it is another user's current password.

    And it is probably an indicator of lax complexity requirements. If passwords conflict often, the users are picking easily-guessed passwords which is itself a problem. (Of course, if complexity requirements are too strict users will just write passwords down, which is another concern. But a password like "tawdry" shouldn't be allowed.)

  • DjadoMraz (unregistered) in reply to John Cowan

    Anonymous:
    What assurance do you have that the error number will be any more stable than the error message?  Both can break very easily.

     

    And you win the prise "moron of the month"!

    Error messages maybe localized in a different country, dude. Numbers however are constant and are unlikely to change even in different versions of the product. You may get different error numbers according to the product version - future versions may provide a better analyzis instead of a plain "syntax error" for example, but the same number would mean the same error always - talking about decent products, not something written by a single self-taught 16 and a half years old person most probably using Perl or Visual Basic.

  • (cs)
    Alex Papadimoulis:

    <FONT color=#000099>if</FONT> (errMsg.indexOf(<FONT color=#990000>"Violation of UNIQUE KEY constraint 'UQ__mbrs_pwd'"</FONT>) != -1)
      <FONT color=#000099>return</FONT> <FONT color=#990000>"The password entered is already in use. Please enter another."</FONT>;

    <FONT face=Georgia>OMFG! First and foremost, why can't two users have the same password? What's the logic there?</FONT>

    <FONT face=Georgia>Of course, the real WTF is the fact that anyone who sees this message now only needs to find the matching username. If this is used only within the company, then usernames probably aren't kept secret, i.e. employee's first letter of the first name followed by their last name.</FONT>

    <FONT face=Georgia>And after you find that user, odds are, they utilize the same password for their banking, Amazon.com and Ebay.com accounts (people shouldn't do that, yet it happens way too often). The possibilities are endless.</FONT>

    <FONT face=Georgia>Now that I think about it, can you forward my resume to this company, Alex? [6]</FONT>

    <FONT face=Georgia>>BiggBru</FONT>

  • (cs) in reply to agent86
    Anonymous:
    Anonymous:
    But now you have the private half of the puzzle, finding the more public half (the username) will be easier. In addition, the password may be a clue as to what the username is. This is a good WTF.


    It seems to me that if the user is permitted to choose both the username AND the password, there is no guaranteed way to ensure uniqueness, without tipping the hand.

    I guess that's why Banks use account numbers, and my Hotmail account was something like JoeBlow753

    Captcha = image, random



    I'm sorry, are you purposing a system in which it's possible for multiple users to have the same username, as long as they have different passwords?

    So if joe accidentally mistypes his password, he might accidentally log in as one of the thousands of other joes?

    brillant!
  • nooooo (unregistered) in reply to BiggBru

    The real WTF is the people that keep posting the same comments over and over. This is obviously a write only forum.

  • (cs) in reply to Baloon Knot
    Anonymous:
    GalacticCowboy:

    Anonymous:
    doing the whole fist thing is stupid.

    Yep, one finger is sufficient.



    I prefer the shocker myself (giving, not receiving).

    <FONT face=Georgia>And I'll never see the silly "Fist!" posts the same way again...</FONT>

    <FONT face=Georgia>And apparently there are more variations of the shocker than I thought. [;)]</FONT>

  • (cs) in reply to nooooo
    Anonymous:
    The real WTF is the people that keep posting the same comments over and over. This is obviously a write only forum.


    A great WTF!  They are comparing error messages instead of using error numbers.  They shouldn't do that.  Or maybe they're just brillant!

    (By the way, Anonymous, I resent your comment.)



  • (cs)

    If I may collate the WTFs from this fine example,

    1. Having a unique key constraint on the password column defies logic, as it means that the same password cannot be used more than once. A constraint on active user names is fine, but one on passwords is dumb.
    2. Indicating to the end-user that a particular password is in use has got to make security experts die with aploplexy! It does not take much imagination to suppose that other security-sensitive information is also provided to the end-user in the form of error messages.
    3. The capture of the error is dependent on the constraint name not changing. So if someone drops the constraint, and then re-creates it with a different name, the duplicate password error as it were would never be discovered (actually, this might be a good thing!!!)
    4. It is a big WTF to use the violation of a constraint to deduce violation of core business rules. It would be by far preferable to have pro-active code doing this.

  • A chicken passeth by (unregistered) in reply to b1xml2

    What's wrong with forbidding different users from having the same password? I know of at least one system where no password may ever be even reused, whether it was you or another user that formerly employed it.

    The end users won't. With time, shortest password length will become too long for the end-user to remember (either that, or the allowed combination becomes too complicated for memory), since all the good shorter length ones (up to the min constraint) have probably been used before.

    Plus, there's risk of running outta passwords, since I trust password fields are not of infinite length, and there are constraints like "no system or unique characters".

    The only way to solve this is to cull the password file of retired usernames from time to time, but it kinda defeats the purpose of enforcing unreusability of passes now, doesn't it?

  • The Anonymous Coward (unregistered) in reply to John Cowan

    Anonymous:
    What assurance do you have that the error number will be any more stable than the error message?  Both can break very easily.

    The entire purpose of an error code is to be programatically recognized.  The purpose of an error message, on the other hand, is to provide human-readable information (on screen or in a log).  To break it down more explicitely:

    1) The error code is part of the databases API.  It is reasonable to expect it not to change from version to version of a product; and if the product developers are any good, then they will avoid changing the codes because they expect their existing user base to be using them in this way.  They need have no such qualms about changing error messages, and in fact is is very likely for error messages to evolve over a product's lifetime.

    2) Error codes aren't localized.

    Obviously this won't protect you if you change database vendors.  It would be nice to have a standard for error codes; but good luck with that.

  • The Anonymous Coward (unregistered)

    The real WTF is the people that keep posting the same comments over and over. This is obviously a write only forum.

  • (cs) in reply to The Anonymous Coward
    Anonymous:
    The real WTF is the people that keep posting the same comments over and over. This is obviously a write only forum.
    I can hardly wait to see what happens when the password can't be written to the database ... oh, nevermind.  (No, I'm not even going to try to link to yesterday's WTF.)
  • erlando (unregistered)

    This sadly reminds me of how things used to work in the system I'm currently working on.

    Except the primary key was username + password. Yes that means you could have two users with the same username if they had different passwords.

    If that's not enough consider this: The system is a community system with a high degree of interaction between users.. "Oh you're not the user1234 I expected you to be"..


    Needless to say things have changed.

  • Dalle (unregistered) in reply to TankerJoe
    TankerJoe:
    12345? That is the kind of password that only an idiot would have on his luggage...

    The password for my luggage is 0000, and it's never even locked. I don't want to buy a new luggage each time the customs/DoD has broken the lock open.
  • maht (unregistered) in reply to kipthegreat
    kipthegreat:


    That's true.  Giving them the benefit of the doubt, they could be storing something like an md5 hash with several randomly-generated salt characters.  In which case, there would need to be somewhere on the order of 1.774 * 2^64 users before the probability of a collision is greater than 50%.  If this were the case, then it is unlikely that this error message was ever seen, which would explain why it was still in the system.  Using an even better hash like SHA-1 would further decrease the probability of a clash.

    Of course, Alex said "this is as bad as it seems" so I doubt it.


    You can't use random salt, or else you will never be able to compare the hash against the plain text.

    You need to use something calculatable such as :

    ptxt = sprintf("%s + %s", username, password);
    hash = md5(ptxt);



  • New Media Guy (unregistered) in reply to Dalle

    <FONT face=Arial>Thinking about this............What if just maybe user details were inserted in to a table when someone logs on and the check is to see if a user is already logged on to the system. This is a true WTF but I hope against hope it is a way to stop same credential sessions in the app??? Possibly......maybe........</FONT>

  • maht (unregistered) in reply to Bus Raker
    Bus Raker:

    It's seems most wireless routers ship with the IP address of 192.168.2.1 or 192.168.1.1, and with a username admin and password admin or blank.

    I'm wondering how fun it would be to code a little Windows service on my laptop and drive around town....



    A few years ago, around when WiFi was initially advertised on TV,  I thought that wardriving around my area searching for open access points would be some naughty way to have some fun, no real criminal intentions, just the illicit thrill of the chase.

    In the few miles from my house to my office there were 30 open, unencrypted access points in various types of building from domestic dwellings in the heroin users lowest rent area to a nice fat 8mb pipe in the City Council Multimedia Centre (which I reported to my friend, the city council network admin peon).

    There's just no fun in it. Changing router settings is tiresomely easy =)


  • (cs) in reply to Enric Naval
    Enric Naval:
    Oh, and I was the one doing the "fist!" first reply today. I just saw "0 replies" and I had to do it.... I had no time to login. I just typed something on the name field so it wouldn't complain

    You are a jerk.
  • maht (unregistered) in reply to John Cowan
    Anonymous:
    What assurance do you have that the error number will be any more stable than the error message?  Both can break very easily.



    Despite the "moron of the month" award, plan9 agrees with you


    The Rerror message (there is no Terror) is used to return an error string describing the failure of a transaction. It replaces the corresponding reply message that would accompany a successful call; its tag is that of the failing request.

    We (worldwide plan9 users) have coped with textual error messages for nearly 20 years now.

    Error numbers tell you NOTHING and are not very grep \ search engine friendly

    Give me
    <font>Violation of UNIQUE KEY constraint 'UQ__mbrs_pwd'

    not

    Error 2535213521.462345.4567347


    </font>
  • habedak (unregistered) in reply to qbolec
    Anonymous:

    Could anyone explain me what is the difference between following attacks:
    1. Try to create new accounts, and check for an error.

    2. Try to log on an account using different passwords?

    I think I know the answer: the first one is easier to spot by administrator. But I do agree that it is a little bit faster -> you'll get a password 1000 times faster if there are 1000 users....is it really a WTF?



    It's very easy to implement something that just bans you from the system if you fail to enter the correct password 3 times in a row...  So knowing an account and guessing a password can easily be prevented (on the system I work with if you get 3 consecutive errors on login, your ip is added in the logs, the administrator gets a mail, and you can't use that account for 24 hours...  (if you contact the administrator and tell him you're just stupid he can unblock the account again).

    If you have a password and you just need to find the correct user, you can attempt every user once.  It's quite hard to prevent that since you can't just block every user on the system after x concecutive systemwide login-failures.  It's indeed easy to spot and log, but if the admin is reading this forum, or slashdot (which is what most admins do :p), you've got a lot of time to find the account.  It's safer if the system itself can prevent you from hacking it then when an admin has to spot it.

    I really liked this wtf, especially the first part... Yesterday I had to make a change to the app we're building to communicate with another system, and the specs of the other system said: 'if the error message contains the string "some string", the error is "SomeError"'  I was thinking about posting it here, since the other software forced me to write such a wtf, but apparently other people are doing it voluntarily.  That's even worse.  I feel relieved now!

  • Anthony (unregistered) in reply to Anon

    Yup, in more than one language that I have looked at, throwning and then catching an exception is a couple of orders of magnitude slower than testing a condition with "if".

    Exceptions are really slow. But only if an exception is thrown. If no exception is thrown, the try..catch block is esentially free. Throwing the exception should be like, you know, exceptional. If it happens all the time, it should be a test not an exception.

    Exceptions are for error handling. And when  your program is falling over, 1/10 of a second isn't going to matter, but a good error log entry does.



  • veritazz (unregistered) in reply to Pablo Marambio

    The funny thing seems to me that if it seems if you've received this specific error message once before,

    the value of this array won't be -1 thus if you enter the password twice, the second time it will be

    accepted!


    gg

  • (cs) in reply to veritazz
    vertiazz:
    The funny thing seems to me that if it seems if you've received this specific error message once before,

    the value of this array won't be -1 thus if you enter the password twice, the second time it will be

    accepted!


    gg



    array? String.indexOf() returns -1 if the needle cannot be found in the haystack. No reason to believe that it will work different the second time.

  • Anonymous (unregistered) in reply to jspenguin
    jspenguin:
    Not to mention the fact that they are RETURNING the error message instead of throwing it.

    The language in the WTF looks very much like JavaScript. While throwing errors in JavaScript is entirely possible, you can't really do that in any sensible way when the goal is to present the error to the end user. (Thrown errors end up in a console, never to be seen by mere mortals)

    I am still amazed that it's possible to reveal three big WTFs in two lines of code.

  • (cs) in reply to rbriem
    rbriem:

    Drum D. -

    Spellcheck your sig ...

    "Two things are infinite: the universe and human supidity, even though I'm not yet sure about the universe.
    - A. Einstein "

    Ah rubbish, at least I didn't write sOupidity.

    Thx for the hint :)

  • Jasper (unregistered) in reply to Drum D.

    This reminds me - and I am not making this up - of when I was working for an online video store in the UK. A competitor started, with press advertisements stating 100% secure. All of our development team visited their site to be presented with a single text box for login. How strange, we all thought, no username/password for them. But was it just username, or password? On trying to register with a username, you would be presented with a message very similar to the one in the OP. Madness. I tried 'Liverpool', a common enough password. It was one of the directors of the company's accounts. I kid you not. Before the end of the day, we'd ordered up "airtighting for beginners" for him (you could also edit the title of the video in the URL).

    It was difficult trying to explain to the lawyers that eventually/inevitably got involved what 'airtighting' meant.

  • UTU (unregistered) in reply to Anonymous

    First, this needs to be addressed...

    Anonymous:
    While throwing errors in JavaScript is entirely possible, you can't really do that in any sensible way when the goal is to present the error to the end user. (Thrown errors end up in a console, never to be seen by mere mortals)


    In Javascript, you can theoretically (meaning it works in IE & FF, but unfortunately not on Opera) overwrite window.onerror with a custom function and do whatever you like with the thrown exceptions - even show it to them mere mortals out there.

    Secondly, even though we can assume, we don't know many things to determine the unique WTFness of this entry;

    a) How is the password stored - as said, it could be MD5 hashed in the database (preferably salted with the username, so that we can't determine if we have the same password as someone else by looking at the contents of the database (of course, if we're able to do that, the system security is already compromised in a more thorough manner than anything that could be done by logging into the application))
    b) Although the name suggests, we don't know if the constraint is only on the password field. It could contain some others, what good would this do, I don't know, but it's a possibility
    c) It would be plausible to have username as primary key, as well as combination username + password fields as unique key. This would speed up the lookups from the database when we're logging in (when we have very huge amount of users).
    d) I'm certain I had d, but I forgot it.

    Well, that's it... of course, there are more, but this was all I could think of from the top of my head.

  • IanB (unregistered) in reply to marvin_rabbit
    marvin_rabbit:
    I'm just trying to imagine the GMail (or other such service) sign-up process if THAT required a unique password:
    <sound of="" typing="">
    "secret", no.
    "password", no.
    "07-04-1776", no.
    "asdfasdfasdf", no.
    "wtf?", no.
    "Reginauld G. Cooper was here", no.
    "Reginauld G. Cooper was THERE", no.
    "are there any f---ing paswords left?", no.
    "spacemonkey", no.
    "deadbabyducks", no.
    "painfullrectalitch", no.
    "superbassamatic76", no.

    I laughed untill I cried - now I've got to explain to everyone sitting near me wtf is wrong with me!
  • Alexee (unregistered)

    BTW, do you know how to get to know that which constraint violated if you can not use the getMessage() of the Exception? I'm using Java, JDBC and I'd like to insert a row into an Oracle table. ( JDBC driver: oracle9i_9.2.0.5_JDK1.3 or oracle9i_9.2.0.5_JDK4 )

    I didn't find other solution that using the getMessage() string...


  • Alexee (unregistered) in reply to b1xml2
    b1xml2:
    1. It is a big WTF to use the violation of a constraint to deduce violation of core business rules. It would be by far preferable to have pro-active code doing this.


    What other solutions do U have? select for update or lock the whole table? I don't think that using an unique constraint violation is bad. Of it is enough to look for the constraint name in the error message and check the error code ( which is ORA-000001 )


  • (cs) in reply to Alexee

    Of course this could be perfectly legit if it just prevents you from changing your password to your current password.

  • (cs) in reply to Stan James

    oops, posted too fast - the test for the error message text still sucks.

  • (cs) in reply to b1xml2
    b1xml2:
    1. It is a big WTF to use the violation of a constraint to deduce violation of core business rules. It would be by far preferable to have pro-active code doing this.


    There is absolutely no value whatsoever to pro-actively check something the database will check anyway. You just ask for race conditions and poor performance; and of course it means more code to write, therefore more chances to introduce bugs.

  • (cs) in reply to JamesCurran
    JamesCurran:

    kipthegreat:
    Anonymous:

    I don't know how you can infer anything about how the password is stored from that snippet of code.  It's just searching the text of an error message; the preceding lines could have included a check of a hashed or encrypted value against the one in the DB.


    That's true.  Giving them the benefit of the doubt, they could be storing something like an md5 hash with several randomly-generated salt characters.  In which case, there would need to be somewhere on the order of 1.774 * 2^64 users before the probability of a collision is greater than 50%.  If this were the case, then it is unlikely that this error message was ever seen, which would explain why it was still in the system. 

    Okay, you are both wrong.

    Anon: There is NO search on the text.  There is just an insert into a db table with a unique contraint on the password field.  (Though it is true that the value entered into that field could be either the plain-text password or the hashed password.  Either way, it would not affect the WTF).

    actually, anonymous is correct - what he means is that the code snippet given is searching the error message string for some text, using errMsg.indexOf() - we have no indication where that message comes from, although your hypothesis that it is a database table insert is probably true.

  • (cs) in reply to apathes
    apathes:
    Alex Papadimoulis:

     ... while blindfolded with your feet



    WTF? ;-)


    Possibly Alex doesn't actually intent to suggest that someone be blindfolded by wrapping their feet around their head.  That would be unnecessarily barbaric.
  • (cs) in reply to maht
    Anonymous:

    Error numbers tell you NOTHING and are not very grep \ search engine friendly

    Give me
    <font>Violation of UNIQUE KEY constraint 'UQ__mbrs_pwd'

    not

    Error 2535213521.462345.4567347
    </font>


    A sensible system will give you BOTH because, yes, error numbers are cryptic. But the rest you got ass-backwards. How the hell is a textual error message "grep \ search engine friendly"? It might get translated or changed for other reasons, breaking any dependency, and when searching for it in a search engine, any typo or other change by you or the person who wrote a document you might be interested will get you no hit.
  • jimbo (unregistered) in reply to Baloon Knot

    The one important bit of info that we're not given here is what table the unique passwords are in.

    Example of why this is important:
    Think of a small application, used by some companies, and some users, like... I don't know... any major authentication system, such as MS Active Directory.

    Now imagine that the AD administrator at a company has set some sensible password restraints, eg a minimum password length, a maximum password age and that the user can't re-use any of their previous x passwords (so that they can't get round the max pw age policy by just reusing the previous password each time).

    Now we have a requirement that a number of passwords are being stored for the one user. Presumably we can imagine an implementation where we'd have a table per user listing all of their previous 10 passwords (hopefully hashed or encrypted in some way), and when they change their password the system needs to check that the new password doesn't match any of the previous ones.

    So of course the person logging in would already know the username, it's theirs, and its not a security breach to reveal that a certain password is already in the system because it was exactly the same user who had that password 6 months ago, so (hopefully) they already knew it.

    Of course one password table per user may not be the ideal database schema, but it sure is much less of a WTF than everyone's suggesting above. Which brings us back to the string matching error messages WTF.

  • (cs) in reply to jimbo
    Anonymous:

    Now we have a requirement that a number of passwords are being stored for the one user. Presumably we can imagine an implementation where we'd have a table per user listing all of their previous 10 passwords (hopefully hashed or encrypted in some way), and when they change their password the system needs to check that the new password doesn't match any of the previous ones.
    ...
    Of course one password table per user may not be the ideal database schema, but it sure is much less of a WTF than everyone's suggesting above. Which brings us back to the string matching error messages WTF.


    Nice theory, but I don't think you can have the same name for the unique key constraints for all those tables.
    BTW, creating a table per user is stupid.
  • (cs)

    Oooh! A WTF^2!!!

    I see:

    • The dumbest way to check for a used password.
    • Checking for a used password! Why can't someone else and I have the same one? it's SECRET right? and only useful in pair with the user id.
    • Passwords that must be globally unique. see above.
    • Security issue with telling someone that what they typed is already someone's password.
    How'd you get code from my old employer!!!!???? :-)

  • (cs) in reply to Jojosh_the_Pi
    Jojosh_the_Pi:
    HatTrick:
    Hmmmm boy doesn't that make a hackers life easier.


    It's not really an issue, because the hacker still doesn't know which user name goes with the password!




    Yeah it is!

    If the hacker can determine that the company uses a certain userid scheme! first initial + last name is pretty common. and if this is a corporate system, you can bet that REALLY narrows it down, all he needs is a phone list!
  • (cs) in reply to TankerJoe

    TankerJoe:
    kipthegreat:
    jspenguin:
    Note to self: change GMail password


    My GMail password is 12345.  I'm very proud of it.  No one would ever guess it.


    12345? That is the kind of password that only an idiot would have on his luggage...

    Evil will always triumph because good is dumb!

  • (cs) in reply to Lexx
    Anonymous:
    I was actually asking myself the other day whether there ever has been someone stupid enough to put a unique constraint on a password field.

    Thank you for taking the last bit of faith I had in humanity.



    There are always lower levels in hell reserved for worse offenses than that.  The last employer I worked for used a legacy ERP system which had been "updated" for the new fangled Intarweb to handle e-commerce, and one of the "features" added was a "web password" field.  This field was not necessarily "unique", as in there not being any constraints on it, but it was treated as an index key when looking up accounts.  The API accepted any number of account-related fields and searched each field in the database, in order, until it found a unique record.  The first field was the Password field, followed by FirstName, Password, Address, City, State, ZipCode, and Phone.  If a unique field could not be found, the system would prompt for any other additional fields.

    When I said that the API accepted "any number" of fields, I meant that it required at least ONE field, and guess which fields were chosen by the developer before me when the e-commerce site was developed?  The Password and LastName fields!

    So in order to prove how insecure this was, I performed the following proof-of-concept hack for them:

    1. Attempt to log in with a very common last name, say "Smith"
    2. Try some very common passwords (you'd be surprised at knowing the chances of someone named "Smith" who chose a password of "password").
    3. When multiple records are found, I'd just try a different state until a hit was made (there's only 50, so its not that hard).

    And so on.

    As an aside, the reason we found out the Password is the key field used in searching the records is because a competitor posted an issue on a support mailing list complaining that their system was taking up to 30 minutes to process a login request after some modifications to their framework.  Turns out that in order to better secure their system, they were using a separate database to store properly policed account username and passwords, but since the password field was required in the back-end record for a web account, they decided to make them all the same to get them out of the way, and just use their properly designed external security layer and just link the accounts by their internal record IDs.  The queries took up to 30 minutes because the system first had to look for all the records that contained the password (in their case all records had the same password), compile a list of results, and then narrow it down with the additional fields submitted.

    WTF?!

         -dZ.

  • (cs) in reply to erlando

    Anonymous:
    Except the primary key was username + password. Yes that means you could have two users with the same username if they had different passwords.

    Brilliant!  That means two different usernames with different passwords could have the same primary key!  Example:

    User: JoeBlow1   Password: 5abcdef   Primary Key: JoeBlow15abcdef

    User: JoeBlow15 Password: abcdef    Primary Key: JoeBlow15abcdef

     

  • qbolec (unregistered) in reply to ammoQ

    I don't know much about constraints, but as pointed out before - do we know what that constraint was meant to do just by looking at it's name?

    I do believe that the table stored 10 previous passwords of each user in ONE table, (ie. pairs USERID,password_hash), and the constraint was just used to check if id,hash(password) was already there. Can you prove me wrong?

    Also I do believe there was no better way for testing the error than parsing the error message. Again I don't know much about constraints, but I don't believe that each constraint has different errorcode...But even if I am wrong and the developer can change the error message so it contains the different error code for different constraint, I still can imagine a language/library set (like maybe PHP) where you cannot get this number directly so the only way is to parse.

    I can also imagine that testing for shorter string like "name_of_constraint" could be better, as it doesn't change via localisation. But still - it may change as pointed out before, and still the name_of_constraint may be in the string for some different reason ...(I dunno:P)..than the constraint violation.

    I can also imagine a world where everything works on English version of the database. In fact I'm from Poland and haven't seen Polish error messages in any database software for ages:)

    I can also imagine that these two lines of code were in file  /mods/english/errorhandling/errors.php or something.

    My imagination reaches even further: maybe each time they got new client in some oversee country they have so much work with localisation, that simple changing error-message-matching code is not such a pain...or maybe they prefer to change the database language...(what's the point of having German error messages in database if you are English-thinking developer, and German-speaking end-users are not supposed to see them anyway?)

    [sorry for grammar/spellings/intonation:P]

  • (cs) in reply to kipthegreat
    kipthegreat:
    jspenguin:
    marvin_rabbit:
    I'm just trying to imagine the GMail (or other such service) sign-up process if THAT required a unique password:
    <sound of="" typing="">
    "secret", no.
    "password", no.
    "07-04-1776", no.
    "asdfasdfasdf", no.
    "wtf?", no.
    "Reginauld G. Cooper was here", no.
    "Reginauld G. Cooper was THERE", no.
    "are there any f---ing paswords left?", no.
    "spacemonkey", no.
    "deadbabyducks", no.
    "painfullrectalitch", no.
    "superbassamatic76", no.

    Note to self: change GMail password



    My GMail password is 12345.  I'm very proud of it.  No one would ever guess it.


    12345?  Amazing!  I've got the same combination on my luggage!

  • Brian Kemp (unregistered) in reply to ZMeson

    User: JoeBlow1   Password: 5abcdef   Primary Key: JoeBlow15abcdef

    User: JoeBlow15 Password: abcdef    Primary Key: JoeBlow15abcdef


    That's beautiful. Utterly beautiful.

    Re; the comment made about salt...I was fairly sure salt was either calculated or stored somewhere.  It's only supposed to make two encrypted passwords different between users, not actually make the password harder to crack on its own merits--just that you only get one account per password cracked.

    My friend came up with the idea of "pepper"--something that is added to a salted password pre-encryption but is the same for all users and would differ on different installations of the same product--almost like an administrator or installation setting, to further annoy vendors of pre-computed hash lists.

    For example:
    username = "BrianKemp"
    password = "12345"
    Pepper = "cayenne"
    Salt = md5((username->ToUnicodeBytes XOR 255) to Hexadecimal)
    hashed password = SHA1(password + salt + pepper)

    So company 1 has pepper "cayenne" and company 2 has pepper "greenbell".  The same username/password combination will not be the same on the two servers.

    The problem is that it's entirely possible to set up a pepper so that it's completely useless if you're using, say, md5:
    If Hash(X) = Hash(Y)
    then Hash(X + Pepper) can equal Hash(Y+Pepper) for very carefully chosen values of pepper.
  • (cs) in reply to marvin_rabbit

    marvin_rabbit:
    I'm just trying to imagine the GMail (or other such service) sign-up process if THAT required a unique password:
    <SOUND typing: of>
    "secret", no.
    "password", no.
    "07-04-1776", no.
    "asdfasdfasdf", no.
    "wtf?", no.
    "Reginauld G. Cooper was here", no.
    "Reginauld G. Cooper was THERE", no.
    "are there any f---ing paswords left?", no.
    "spacemonkey", no.
    "deadbabyducks", no.
    "painfullrectalitch", no.
    "superbassamatic76", no.

    Let's not forget "Jesus" (who in this case does not save...)

  • qweraasd (unregistered) in reply to Pablo Marambio

    So, password for unique key maybe? please vote

  • Vulgar Warrior (unregistered) in reply to kipthegreat

    kipthegreat:
    jspenguin:
    marvin_rabbit:
    I'm just trying to imagine the GMail (or other such service) sign-up process if THAT required a unique password:
    <SOUND typing="" of="">
    "secret", no.
    "password", no.
    "07-04-1776", no.
    "asdfasdfasdf", no.
    "wtf?", no.
    "Reginauld G. Cooper was here", no.
    "Reginauld G. Cooper was THERE", no.
    "are there any f---ing paswords left?", no.
    "spacemonkey", no.
    "deadbabyducks", no.
    "painfullrectalitch", no.
    "superbassamatic76", no.
    Note to self: change GMail password


    My GMail password is 12345.  I'm very proud of it.  No one would ever guess it.

    What kind of password is that?  That's the sort of password you'd use on your luggage!

     

    I can see all sorts of fun coming from this one...

       1) Try to insert record -> locks table while doing so (what happens if there's 100 people creating passwords at the same time?)

       2) Reads an error message containing a specific constraint name (what happens if the table needs to be dropped and re-   created due to corruption, odds are someone won't remember to re-create the constraint using the exact name)

       3) Unless there's something to delete old passwords from this password table, then you wouldn't be able to re-   use any password created...ever.

    Although there's nothing indicating that the passwords are stored as plain text..it could be passing anything to the db.

  • (cs) in reply to Baloon Knot
    Anonymous:
    Alex Papadimoulis:

    ...I'll present a single line of code...

    <font color="#000099">if</font> (errMsg.indexOf(<font color="#990000">"Violation of UNIQUE KEY constraint 'UQ__mbrs_pwd'"</font>) != -1)
      <font color="#000099">return</font> <font color="#990000">"The password entered is already in use. Please enter another."</font>;


    I get it, the WTF is that Alex said he'd present a single line of code, but he really showed two.


    well, it seems that since there's only one semicolon, that it is just one line of code.
    word wrappage in full effect.

Leave a comment on “Uniquely Secure”

Log In or post as a guest

Replying to comment #72334:

« Return to Article