Web shop WTF



  • It took me very long before finally getting a credit card because I never really trusted them. In the time before I got one, I was bombarded with credit card fraud stories in the news papers and on the internet. Now that I have one, I treat it very carefully... always leaving it at home when I don't particularly need it, and never save the information on a website.

     

    Yesterday I went to do some shopping on a website that I hadn't ordered from in a while and I forgot my password. I clicked the retreive password link and the password got mailed to me. Plain text in an email. I wasn't too fussed about it,... I know it's a bad practice but what do I care, it's just the log in to some arbitrary webshop. When I was done shopping I went to checkout and to my surprise... they had saved my credit card information and I could almost just order the stuff without filling in any information (not even that short security code on the back).

    I say almost, because apparently there's some new kind of security, I think it was called SecureCode or something, which I had to sign up for. I had to make up a password and only with that password could I accept the transaction (and any future transactions, I reckon). But then I saw the password limitations: "6 to 12 characters, no spaces". Naturally I went into a furious rage... my credit card information is just about my most important information on the internet, why would you put such restrictions on the password? But when my rage was over, I got think... why do they put those restrictions on? Is it a technical limitation? If so, what kind of stupid database do they store my information in? If not, which retard came up with it?

    So to sum up:

    - A password sent to me plain text in an email to access a website which has stored my most crucial information (all of my credit card information, including the "security" code);

    - Stupid limitations on securing my on-line credit card transactions with a password.

     

    I sat in my chair, glared at the screen and exclaimed "WTF!?"



  •  me too! i am always wondering why those strage pwd limitations on various pages... i store passwords in varchar(64), md5-ed, and never had to limit anything...

    (yup, md5 has static length, and its less than 64 characters, i think, but i can never remember what exact length it is, so once i said to myself "screw it, from now on, i'll always use 64 character length on my pwd fields" :-D )



  • @SEMI-HYBRID code said:

     me too! i am always wondering why those strage pwd limitations on various pages... i store passwords in varchar(64), md5-ed, and never had to limit anything...

    (yup, md5 has static length, and its less than 64 characters, i think, but i can never remember what exact length it is, so once i said to myself "screw it, from now on, i'll always use 64 character length on my pwd fields" :-D )


    I also use one-way hash algorithms but more out of ignorance for any alternatives or "real" encryption. I use SHA-1 though, since MD5 has been defeated and now is considered weak (although for password hashing this isn't as big as a problem as for verifying files which could be malicious like executables). MD5 is 128bit, so to store it as a hexadecimal string you need 32 characters, while SHA-1 is 160bit so you'd need 40 characters.



  • @pbean said:

    MD5 is 128bit, so to store it as a hexadecimal string you need 32 characters, while SHA-1 is 160bit so you'd need 40 characters.
     

     thanks! :-)



  • @SEMI-HYBRID code said:

    (yup, md5 has static length, and its less than 64 characters, i think, but i can never remember what exact length it is, so once i said to myself "screw it, from now on, i'll always use 64 character length on my pwd fields" :-D )
    You were too lazy to search the net / read it on Wikipedia. I can identify with that. But varchar instead instead of char, that's just wrong.



  • @pbean said:

    - A password sent to me plain text in an email to access a website which has stored my most crucial information (all of my credit card information, including the "security" code);
     

    Including your security code?  Report that merchant to your carrier because as far as I am aware this security code is never supposed to be saved at all, never ever, no way.  It is not used for record keeping, tracking, chargebacks etc, it is only used for the initial transactuion then can be forgotten.  If thier processor needs it, they are suppose to ask for it again each time.



  • Personally, I like when they store my CC info, though they never store the three digit security code and I have to put that in every time.

    Ask the merchant to delete all your info, never shop there again, then tell us who this worthless merchant is, so we can never go there.



  •  Clearly, TRWTF is that you knew this site had such horrible security that they stored your password in plaintext, and still decided to do business with them. 



  • @pbean said:

    @SEMI-HYBRID code said:

     me too! i am always wondering why those strage pwd limitations on various pages... i store passwords in varchar(64), md5-ed, and never had to limit anything...

    (yup, md5 has static length, and its less than 64 characters, i think, but i can never remember what exact length it is, so once i said to myself "screw it, from now on, i'll always use 64 character length on my pwd fields" :-D )


    I also use one-way hash algorithms but more out of ignorance for any alternatives or "real" encryption. I use SHA-1 though, since MD5 has been defeated and now is considered weak (although for password hashing this isn't as big as a problem as for verifying files which could be malicious like executables). MD5 is 128bit, so to store it as a hexadecimal string you need 32 characters, while SHA-1 is 160bit so you'd need 40 characters.

    You should be using bcrypt.  If that's not available, you should be using multi-pass, per-user-salted SHA.  Storing unsalted, single-pass password hashes is only marginally better than plaintext.



  • @Zecc said:

    But varchar instead instead of char, that's just wrong.
     

     sorry, i'm a homebrew programmer, i never really studied it in any institution, and i didn't even know that the char type existed, until now...

     yup, i read manuals only when i don't know how to make something work, and i read them only to the point when i find it out.

    is there really that big difference in speed?



  • @SEMI-HYBRID code said:

    @Zecc said:

    But varchar instead instead of char, that's just wrong.
     

     sorry, i'm a homebrew programmer, i never really studied it in any institution, and i didn't even know that the char type existed, until now...

     yup, i read manuals only when i don't know how to make something work, and i read them only to the point when i find it out.

    is there really that big difference in speed?

    Depends on the database engine.  Some treat chars internally just like varchars, and only pad out the column when returning data.  Others make a distinction between variable-width tables and fixed-width tables.



  • For the sake of everyone, please report this merchant to Visa or Mastercard for PCI-DSS non-compliance.  Although storing card numbers is generally frowned upon, it is permissible if, and only if, proper security measures are taken (doubtful in this case).  However, it is NEVER permissible to store the CVV2 code from the back of the card.

    As for the SecureCode thing, MasterCard (and Visa which has a similar program to SecureCode) are both running on legacy hardware with the software written in COBOL (and probably using DB2 as the backend).  It is unlikely they are using variable length fields.

    Note: I work in the credit card processing industry (on the merchant processing side, so please don't complain to me about your credit card company screwing you on fees...  unless you are a merchant and don't like your rates, then I can refer you to someone.)

     

    I offer my sincere apologies for throwing a subtle ad in at the end.



  • @morbiuswilters said:

    Depends on the database engine.  Some treat chars internally just like varchars, and only pad out the column when returning data.  Others make a distinction between variable-width tables and fixed-width tables.
     

    I always use mysql. Easy, quick to work with, nice, and i've never done anything that would need something "more robust" or "enterprisey".



  • @morbiuswilters said:

    You should be using bcrypt.  If that's not available, you should be using multi-pass, per-user-salted SHA.  Storing unsalted, single-pass password hashes is only marginally better than plaintext.
    Wait, I thought that hashing something multiple times reduced entropy.  Is that only true of MD5?



  • @belgariontheking said:

    @morbiuswilters said:

    You should be using bcrypt.  If that's not available, you should be using multi-pass, per-user-salted SHA.  Storing unsalted, single-pass password hashes is only marginally better than plaintext.
    Wait, I thought that hashing something multiple times reduced entropy.  Is that only true of MD5?

    I think you're thinking of encrypting something multiple times with the same key.  Some algos are less secure when used that way.  Multi-pass MD5 is what OpenBSD (or was it FreeBSD?) used for years in its password hashing, so it's likely very secure as it was the "gold standard" in password hashing at the time.



  • @SEMI-HYBRID code said:

    @morbiuswilters said:

    Depends on the database engine.  Some treat chars internally just like varchars, and only pad out the column when returning data.  Others make a distinction between variable-width tables and fixed-width tables.
     

    I always use mysql. Easy, quick to work with, nice, and i've never done anything that would need something "more robust" or "enterprisey".

    MySQL is fairly robust and "enterprisey" nowadays.  Anyway, MySQL uses several backend engines.  Basically, MyISAM handles variable-width tables differently than fixed-width tables.  InnoDB does not, AFAIK.



  • @SEMI-HYBRID code said:

    @Zecc said:

    But varchar instead instead of char, that's just wrong.
     

     sorry, i'm a homebrew programmer, i never really studied it in any institution, and i didn't even know that the char type existed, until now...

     yup, i read manuals only when i don't know how to make something work, and i read them only to the point when i find it out.

    is there really that big difference in speed?

    Actually, I was mostly messing with you. I don't really have any experience in terms of performance of char vs varchar. I'm just very picky when it comes to semantics.

    But really, my first post was me being mostly sarcastic, as per forum tradition.



  • @belgariontheking said:

    @morbiuswilters said:
    You should be using bcrypt.  If that's not available, you should be using multi-pass, per-user-salted SHA.  Storing unsalted, single-pass password hashes is only marginally better than plaintext.
    Wait, I thought that hashing something multiple times reduced entropy.  Is that only true of MD5?
    No, it's true of any hash function, assuming you just keep feeding the output back into the hash, as in h1 = Hash(message), hi+1 = Hash(hi).  However, there's a simple fix: just do hi+1 = Hash(hi || message) instead (where || denotes concatenation).  Or hi+1 = Hash(hi || h1) or anything else that keeps mixing the original data back into every step.



  • @vyznev said:

    However, there's a simple fix: just do hi+1 = Hash(hi || message) instead (where || denotes concatenation).  Or hi+1 = Hash(hi || h1) or anything else that keeps mixing the original data back into every step.

    Which is how multi-pass password hashing is done.



  • @pbean said:

    When I was done shopping I went to checkout and to my surprise... they had saved my credit card information and I could almost just order the stuff without filling in any information

    Let these guys know.



  • The way salting works, (at least as far as I understand it, which very well may be wrong), you do the following:

    1) Hash the password

    2) Generate an as-random-as-possible salt

    3) Append the salt to the end of the password hash

    4) Hash that, too

    5) Store that hash and the salt in the DB

    6) Repeat the above process (except reading the existing salt from the DB instead of generating one) whenever you need to authenticate.



  • @blakeyrat said:

    The way salting works, (at least as far as I understand it, which very well may be wrong), you do the following:

    1) Hash the password

    2) Generate an as-random-as-possible salt

    3) Append the salt to the end of the password hash

    4) Hash that, too

    5) Store that hash and the salt in the DB

    6) Repeat the above process (except reading the existing salt from the DB instead of generating one) whenever you need to authenticate.

    That works, but generally what you see is something like hash(salt + password).  Or hash(salt + password + last_hash), if you doing several passes (which you should be).  Although, I will state it once again: don't write your own password hashing routines.  Use bcrypt or some other suitably-strong library from a trusted source.



  • @morbiuswilters said:

    That works, but generally what you see is something like hash(salt + password).  Or hash(salt + password + last_hash), if you doing several passes (which you should be).  Although, I will state it once again: don't write your own password hashing routines.  Use bcrypt or some other suitably-strong library from a trusted source.

    Ah, well, I have enough users that I'm not going to change how it works now. Good to know it's acceptable, from someone who didn't just pull it from a quickly-Googled website and potentially knows what they are talking about.



  • It took me very long before finally getting a credit card because I never really trusted them. In the time before I got one, I was bombarded with credit card fraud stories in the news papers and on the internet. Now that I have one, I treat it very carefully... always leaving it at home when I don't particularly need it, and never save the information on a website.

    What exactly are you afraid will happen? I had my card number stolen and used to purchase $3000 worth of video game equipment. I called my credit union, disputed the charge, they reversed it, sent me a new card. And life continued. Yawn.



  • @SEMI-HYBRID code said:

    i read manuals only when i don't know how to make something work, and i read them only to the point when i find it out.

     

    Dear Semi,

    When I learn a new language, I read the reference manual cover to cover. Then I use it for a few months. Then I read the reference manual cover to cover again. It's amazing how much I missed the first time through.

    Reading a language manual only to learn how to do something that you already know it can do misses half the fun of any new language. The great things are the stuff that you didn't realize it could do, that you never even thought of doing. It can do things that you never thought a computer could do.

    Read a reference language for fun, for entertainment, for amazing your friends.



  • The website was actually Play.com, which I think is pretty big in Europe. I am not 100% sure they store the security code, but as far as I know you need the security code to complete a transaction and I was able to complete a transaction before without supplying the security code (before they had that SecureCode thingey).



  • @smxlong said:

    I had my card number stolen and used to purchase $3000 worth of video game equipment. I called my credit union, disputed the charge, they reversed it, sent me a new card. And life continued. Yawn.
    In unrelated news, smxlong recently received $3000 worth of video game equipment as a gift from an aunt.



  • @pbean said:

    The website was actually Play.com, which I think is pretty big in Europe. I am not 100% sure they store the security code, but as far as I know you need the security code to complete a transaction and I was able to complete a transaction before without supplying the security code (before they had that SecureCode thingey).

     

    I actually found out just yesterday that Valve's Steam service does the same thing. I was buying a gift for a friend, and the wizard was like ... 1 step long. It didn't ask for my CCV, and at no time did I (mean to) authorize storing it.

    Amazon lets you optionally store it, but it makes it blatantly obvious what you're doing and what the consequences are. You have to sign up for a special program to do it.



  •  @pbean said:

    The website was actually Play.com, which I think is pretty big in Europe. I am not 100% sure they store the security code, but as far as I know you need the security code to complete a transaction and I was able to complete a transaction before without supplying the security code (before they had that SecureCode thingey).

    Actually, the CVV2 code is not required for transactions (neither is AVS, aka address verification)  The merchant can choose not to accept transactions without this data (which they should, since it is a CYA issue).


  • I never had to choose anything special to have Amazon and PayPal store my credit card info - I provided the CCV code on the first purchase, but never afterwards.



  • @ender said:

    I never had to choose anything special to have Amazon and PayPal store my credit card info - I provided the CCV code on the first purchase, but never afterwards.

    Ditto that.  I don't care if Amazon or PayPal store my info, because I trust them.  When shopping online, I'm either buying from Amazon, buying from someone who takes PayPal or I generate one of those "temporary use" account numbers that some banks offer, setting it to expire in a month and with a dollar limit just over my total.


  • Discourse touched me in a no-no place

    @ender said:

    I never had to choose anything special to have Amazon and PayPal store my credit card info - I provided the CCV code on the first purchase, but never afterwards.
    Presuming they aren't storing the CVV2 (which they shouldn't, and should VISA discover on an audit that they are, then they're in trouble,) then they're ostensibly taking the risk for any fraudulant use on the card.



    Presumably they take the view that the first person to have the card in their possession to use it on the account is the authorized owner, and assume that remains the case for future transactions until discovering otherwise.


    What do they do if a 3rd party orders stuff on your account if they find out/guess your Amazon/PayPal credentials? Are you liable? Can you claim back for any fraud? I'm not sure of the position in the UK, and it'll probably differ in the US.



    All the CCV2 does is prove the person using the card in a CNP transaction either

    • has the card in their possession or
    • knows what it is
    Hence SecureCode (and the other one) to provide the semblence of more security. 1.1 factor authentication and all that.


  • @Zecc said:

    In unrelated news, smxlong recently received $3000 worth of video game equipment as a gift from an aunt.

    If we were swinging it that way, the purchase of the physical items wouldn't have been made in Italy. The shipping to the US would have been a bitch.



  • @belgariontheking said:

    @morbiuswilters said:

    You should be using bcrypt.  If that's not available, you should be using multi-pass, per-user-salted SHA.  Storing unsalted, single-pass password hashes is only marginally better than plaintext.
    Wait, I thought that hashing something multiple times reduced entropy.  Is that only true of MD5?

    Remember, just because morbs sounds like he knows what he's saying doesn't mean he's right.  We all have our WTFs.

    Personally, I feel that if a hash algorithm needs me to do additional work to make it more secure, I need a different hash algorithm.  For example, at work, we use a Salted Secure Hash Algorithm for our password storage.  We stick a password in, we get a SSHA out.  We stick the same password in, we get a different SSHA out.  No fuss, no mess.

    Multi-pass hashing is just saying you don't trust your hash authors, but don't know enough about the subject to make your own hash algorithm.



  • @tgape said:

    Remember, just because morbs sounds like he knows what he's saying doesn't mean he's right.  We all have our WTFs.

    Personally, I feel that if a hash algorithm needs me to do additional work to make it more secure, I need a different hash algorithm.  For example, at work, we use a Salted Secure Hash Algorithm for our password storage.  We stick a password in, we get a SSHA out.  We stick the same password in, we get a different SSHA out.  No fuss, no mess.

    Multi-pass hashing is just saying you don't trust your hash authors, but don't know enough about the subject to make your own hash algorithm.

    Um, no.  Multiple passes of the hashing algo are used to eat up CPU time, to make brute-forcing the hashes more difficult.  It's called "key stretching", has a solid foundation in cryptography and has been used for decades to strengthen password hashing schemes.



  • @PJH said:

    Hence SecureCode (and the other one) to provide the semblence of more security.
    My previous bank had this solved in an interesting way - they gave me one of these, and after making purchases online, I'd be redirected to bank's site for card verification, where I got a number to enter into the reader, which would calculate (after entering my PIN) another number for me to enter on bank's site. Only then the transaction was approved.
    @tgape said:
    Multi-pass hashing is just saying you don't trust your hash authors, but don't know enough about the subject to make your own hash algorithm.
    It's actually called key strengthening, and its intention is to take more CPU time to calculate the hash, significantly slowing down brute-force attacks.



  • @tgape said:

    Personally, I feel that if a hash algorithm needs me to do additional work to make it more secure, I need a different hash algorithm.  For example, at work, we use a Salted Secure Hash Algorithm for our password storage.  We stick a password in, we get a SSHA out.  We stick the same password in, we get a different SSHA out.  No fuss, no mess.

    You should never, never, NEVER just use crypto without understanding at least a little about how it works. There are plenty of examples of perfectly good crypto being used in stupid ways where, if the designers had RTFM on the algorithms they used, the end result wouldn't have been a total failure. Take WEP for instance -- it uses RC4 for its encryption but reuses what are supposed to be one-time-pads. Thus what COULD have been nearly as strong as WPA ended up a total failure that can be broken in 10 minutes.

    Screw up using practically any crypto and you can introduce vulnerabilities.

    @tgape said:

    Multi-pass hashing is just saying you don't trust your hash authors, but don't know enough about the subject to make your own hash algorithm.

    Never mind that your SSHA is probably just an already-coded implementaion of multipass MD5 or SHA-1...



  • @joemck said:

    @tgape said:

    Multi-pass hashing is just saying you don't trust your hash authors, but don't know enough about the subject to make your own hash algorithm.

    Never mind that your SSHA is probably just an already-coded implementaion of multipass MD5 or SHA-1...

    Thank you for indicating that you missed my entire point so succinctly.

    My point is not that multi-pass shouldn't be done, but that it should be done by specialists.  The rest of us should just utilize their work, according to how their work is supposed to be used.  It's too easy for one of the uninitiated to do something like using RC4 for its encryption, but reuse what are supposed to be one-time pads.  After one does that, what could've been really good security winds up being a joke.

    While one would, in an ideal world, understand their crypto algorithms, there are many people out there who are not able to do that.  Some of them don't have the time.  Others don't have the mental ability.

    I am therefore of the opinion that one shouldn't muck with the algorithms unless one is competent enough to know what they're doing.



  • @tgape said:

    Thank you for indicating that you missed my entire point so succinctly.

    My point is not that multi-pass shouldn't be done, but that it should be done by specialists.  The rest of us should just utilize their work, according to how their work is supposed to be used.  It's too easy for one of the uninitiated to do something like using RC4 for its encryption, but reuse what are supposed to be one-time pads.  After one does that, what could've been really good security winds up being a joke.

    While one would, in an ideal world, understand their crypto algorithms, there are many people out there who are not able to do that.  Some of them don't have the time.  Others don't have the mental ability.

    I am therefore of the opinion that one shouldn't muck with the algorithms unless one is competent enough to know what they're doing.

    This contradicts your earlier whining at me.  I've always advocated that people use off-the-shelf crypto.  I'm not suggesting anyone implement their own scheme.  However, for the purposes of educating you, single-pass MD5 or SHA-1 are not considered very good solutions for hashing passwords.  On modern, commodity hardware brute forcing salted MD5/SHA-1 takes surprisingly little time.  That's why using expensive password hashing algorithms has been standard practice for decades.  That you don't know this illustrates your profound ignorance on the subject.

     

    And, for the record, the general consensus now seems to be that digest hashing algorithms like MD5 or SHA-1 are inherently insecure and that they will always, always be broken eventually.  So I guess they don't "trust" themselves.



  • @morbiuswilters said:

    This contradicts your earlier whining at me.

    Re-reading my prior post, I don't see a contradiction.  I suspect that this is one of those times when I have failed to communicate correctly.

    If someone feels that a particular hash algorithm should be used with multiple passes, and writes up an algorithm that does that and distributes it, telling the world what they've done and allowing the world to critique it and say whether it's good or a WTF, that's fine.  I do see that I forgot to mention explicitly in my second post that one competent to muck with the algorithms would naturally submit the result for critique.

    If someone cuts out part of that process, and does not submit their security code for review by the global crypto community, I see that as similar to someone who writes their own routine from scratch and doesn't submit it to the global community.  It could be good, but it's hard to say if it is or not.  I don't want to recommend that people do that.

    We use the SSHA algorithm we use because it's the strongest hash algorithm our proprietary vendor supports.  We've found that when we complain about the hash algorithm strength, it takes them long enough to implement the next one that what had been state of the art has been cracked by the time they finish - not that they would attempt to implement what was currently the state of the art; no, they'd go down a grade or two, to something "matured" more.  Bah.  I was not attempting to say that SSHA was a good algorithm, but rather that it was a good interface.


Log in to reply