American Express security measures



  • Let's count a few WTFs:

    • Passwords must be 6 to 8 characters long, no longer. (wtf123xyzzy is invalid!)
    • Passwords canNOT contain any "special characters" (just letters and numbers, please).
    • Security questions canNOT contain these either

    It's not a Javascript-based password system, but ... they are explicitly limiting my security! GAAH!



  • I complained to them about that once pretty loudly while canceling my card and they said that their card security team and fraud teams somehow make up for the lack of good security on the website, and they seemed surprised that I was annoyed at the horrendous design of the site.



  • For the record, my AMEX was revoked two times in a year cos someone got card numbers and they replaced those cards. sweet.



  • Are security question answers limited to 6-8 characters too? (god help you if your favorite color is red)



  • @fennec said:

    Passwords must be 6 to 8 characters long, no longer. (wtf123xyzzy is invalid!)

    Passwords canNOT contain any "special characters" (just letters and numbers, please).

    Hey, I think you've just described 2 out of 3 banks! 2 of 3 will not allow > 8 character passwords, and all 3 expect me to use letters and numbers only. I still wonder on why they do this, as the auth process itself doesn't have any issues with non-alpha characters.... or at least one of those doesn't have those issues. Its just the front-end that doesn't let you put in those passwords.

    The only reason I'd see on doing this is different keyboard layouts. We have two of these over here, the ES and the more popular LA layout. Even though LA is more popular, we do have layout mixups where symbols just map on different keyboards, and causing things like people using àèìòù instead of áéíóú (Note: Spanish does not use the "backtick" accent at all.)

    My all-time favorite is RACF, 8-char passwords are basically mandatory as trying to type a longer password is impossible on the ISPF login screen. If you do type it though, it will do weird stuff. Don't do it.



  • Once more I'm grateful for the technological marvel that is HBCI (the German homebanking standard). You only get a five-digit PIN, but that PIN only works in conjunction with a smartcard. Works quite well (even under Linux and OS X) and doesn't even require fractional numbers to express how many factors are involved in the authentication.



  • It makes more sense when you stop to consider that most of these applications are running against ancient COBOL systems most likely using a flat-file database with fixed-width fields. Expecting these beasts to graciously accept arbitrary-length Unicode is like expecting Windows 3.1 to run Supreme Commander.



  • @Aaron said:

    It makes more sense when you stop to consider that most of these applications are running against ancient COBOL systems most likely using a flat-file database with fixed-width fields.

    Yup, very true; and they use EBCDIC as they run on mainframes. But at least one of the cases I mentioned can handle the non-alpha passwords, as the auth is done by LDAP which basically can receive anything as a password. Granted though, that other systems linked to RACF (internal users mostly) do not like anything other than alpha characters!

    So maybe some banks are using RACF for client auth, which would be a major WTF because banks are legally obligated not to give mainframe access to non-employees. I doubt it though, but it is possible for some of them having some kind of password auth on the mainframe. Ooooh how much fun!

    Trivia: RACF = Resource Access Control Facility, or the security layer for IBM mainframes.



  • @Aaron said:

    It makes more sense when you stop to consider that most of these applications are running against ancient COBOL systems most likely using a flat-file database with fixed-width fields. Expecting these beasts to graciously accept arbitrary-length Unicode is like expecting Windows 3.1 to run Supreme Commander.
     

    Makes sense?  Perhaps.  Excusable?  Not by a long shot.



  • @Aaron said:

    It makes more sense when you stop to consider that most of these applications are running against ancient COBOL systems most likely using a flat-file database with fixed-width fields. Expecting these beasts to graciously accept arbitrary-length Unicode is like expecting Windows 3.1 to run Supreme Commander.
     

    Not accepting arbitary Unicode or extended-ASCII would be reasonable, but not allowing arbitary printing ASCII characters is less justifiable. 

    My bank forces passwords to be 6 alphanumeric chars exactly.



  • Banks are still stuck in the old day and age where 4-digit PIN numbers are "acceptable"  -- they see PIN number length as acceptable, so they see no fault with low-character count passwords and see no need to correct that fact. Fact is (regrettably), a secured desktop machine is probably much more secure than a bank's system when it comes to logons and user access.



  • @Physics Phil said:

    My bank forces passwords to be 6 alphanumeric chars exactly.

    Still running CDC?

     



  • @DigitalXeron said:

    Banks are still stuck in the old day and age where 4-digit PIN numbers are "acceptable"

    A four-digit PIN is perfectly fine when the card is forcibly canceled after three failures.



  • @Aaron said:

    It makes more sense when you stop to consider that most of these applications are running against ancient COBOL systems most likely using a flat-file database with fixed-width fields. Expecting these beasts to graciously accept arbitrary-length Unicode is like expecting Windows 3.1 to run Supreme Commander.

    That's um, pretty much implying they store the passwords in plaintext then, and not some hash of the password?


    Otherwise, there would be no need to even pass special characters past the webserver's application layer, regardless of the ancient legacy systems that it would end up talking to.  This just keeps getting better.


Log in to reply