4 ms·

Yeah, this "we can't extend password beyond 8 characters because legacy systems" argument does not hold water. My experience: built a Web site/app for: a) majo

Yeah, this "we can't extend password beyond 8 characters because legacy systems" argument does not hold water. My experience: built a Web site/app for: a) major bank b) major corp, back in the days when Web presence was kind of a new thing. ~15-20 years ago. You build a new (Web) app and treat the legacy system (happened to be some mainframe) as a backend or whatever. Add new tables to hold user's credentials, email addresses, and whatever else. Link the "new" credentials with the old "account id on mainframe" or whatever. Not really rocket science. BTW - there was no such thing as an "old password table with max 8 character", not for retail customers. Retail customer did not have a password, or email.

IncRnd 7y ago
>> Add new tables to hold user's credentials, email addresses, and whatever else. Adding a table to hold users' credentials doesn't really solve the problem that is being discussed, which is storing users' credentials. All that does is add a new attack surface, stealing the new credentials, and the original credentials are still in the same position.
- carterehsmith 7y ago
  >> Adding a table to hold users' credentials doesn't really solve the problem that is being discussed, which is storing users' credentials. ? Not sure if serious.
- aembleton 7y ago
  You can salt and hash the new password; and the old password can be in plain text. The old password being in plain text doesn't matter so much if it is not possible to access the legacy system directly from outside of the banks network.
- imtringued 7y ago
  Yes, you are right but we are talking about potential causes of these strange policy decisions. One source is simply old software that cannot be updated but this sub-thread is trying to debunk that by saying that you can have a modern table with hashed passwords and a generated secret value that conforms legacy restrictions. The secret value can be used as a password on the old mainframe. There will be collisions but they can be prevented by comparing usernames. There is no technical excuse for not hashing passwords.
o-__-o 7y ago
Until 3 years ago, J.P. Morgan chase would only store the first 8 characters of your password. They would accept more but silently discard it
- carterehsmith 7y ago
  >> Until 3 years ago, J.P. Morgan chase would only store the first 8 characters of your password. They would accept more but silently discard it Oh, I am sure they do. The big question for this thread is: how come this "8-character all-uppercase" password is a thing in States, but less of a thing in e.g. Europe.
  - o-__-o 7y ago
    *did There was a forced password reset that enabled real password policies.

IncRnd 7y ago

>> Add new tables to hold user's credentials, email addresses, and whatever else. Adding a table to hold users' credentials doesn't really solve the problem that is being discussed, which is storing users' credentials. All that does is add a new attack surface, stealing the new credentials, and the original credentials are still in the same position.

carterehsmith 7y ago
>> Adding a table to hold users' credentials doesn't really solve the problem that is being discussed, which is storing users' credentials. ? Not sure if serious.
aembleton 7y ago
You can salt and hash the new password; and the old password can be in plain text. The old password being in plain text doesn't matter so much if it is not possible to access the legacy system directly from outside of the banks network.
imtringued 7y ago
Yes, you are right but we are talking about potential causes of these strange policy decisions. One source is simply old software that cannot be updated but this sub-thread is trying to debunk that by saying that you can have a modern table with hashed passwords and a generated secret value that conforms legacy restrictions. The secret value can be used as a password on the old mainframe. There will be collisions but they can be prevented by comparing usernames. There is no technical excuse for not hashing passwords.

o-__-o 7y ago

Until 3 years ago, J.P. Morgan chase would only store the first 8 characters of your password. They would accept more but silently discard it

carterehsmith 7y ago
>> Until 3 years ago, J.P. Morgan chase would only store the first 8 characters of your password. They would accept more but silently discard it Oh, I am sure they do. The big question for this thread is: how come this "8-character all-uppercase" password is a thing in States, but less of a thing in e.g. Europe.
- o-__-o 7y ago
  *did There was a forced password reset that enabled real password policies.