"Type your password into your telephone"; already they're asking me to do the wrong thing. If my password is anywhere near secure, then typing it into a phone would be a nightmare. A combination of 16 numbers and letters that I need to convert to numbers? I'd be pressing zero and hoping for an operator before I even opened up my password vault to find the secure password to begin with.
If you want a phone interface, give me a PIN option. Sure you'll not want me to be able to buy plane tickets with just the PIN, but that should be sufficient to protect user data.
The original SABRE dates back to the 1950s, and was not an airline-customer-facing system; SABRE dates to an era when the phone interface was used by airline ticket agents.
So if you're going to argue that the design is wrong, you need to argue for why it was wrong for the 1950s use case and interaction patterns, not try to retrofit 2014's use cases and interaction patterns onto it.
The architecture might have been state of the art and completely reasonable back in "ye olden days". The fact remains that it's not appropriate for 2014.
If the reasons for this behemoth are compatibility with 50 years old processes, then these processes have to be modernized so this software can be scrapped. (or fixed, either way a huge project)
How so? So people can use Q's and Z's in their passwords? What would your business case look like? "Hey everybody let's spend $500 million so people can use arbitrary passwords, because [entropy], never mind most people use the name of their cat anyway?"
As ridiculous as that pitch might sound, it makes the implied security-money tradeoff directly visible to management and causes them to make a formal decision.
How so? if it's been used for 60 years, how many records do you think would be compromised if someone gained access to the system? Millions? Billions? Sounds like a good reason to 'modernize' to me.
The target breach would be nothing compared to the breach of a system in use for 60 years.
If their computer system is from the 1950's and they can't modernize it, why don't they also allow smoking and box cutters on the plane, and dress their stewardesses up all sexy?
There's a reason we invented the term bit rot and this is probably one of the reason only in this case the code works perfectly fine it's just the entire use case that is outdated.
Instead of bringing the code into 2014 they would bring the world into the 1950's.
DTMF/Touch-Tone wasn't introduced until 1963 (and then being an extra-cost option from the Bell System). So more like "Dial your password into your telephone". Rotary phones didn't have Q or Z either.
Wow. Passwords on the phone? You've changed the password strength from a combination of 26 lowercase letters + 26 upper case letters + 10 digits + 30 punctuation characters to just 12 characters. For an 8 character password that goes from (92^8)/2 to (12^8) permutations of characters.
But this is silly really, because I've never seen a case sensitive phone keypad, which is part of their complexity requirements.
How do you type your password into your telephone, something this system has to support?
There's a lot of speculation in the thread that this is the reason, and it's not a totally unreasonable guess. If this is the reason, then you're right, my scheme would not be suitable.
While we're all guessing, though, I think there are reasons to doubt a "password via DTMF" requirement. Look at the other rules: Passwords are case sensitive, must contain both letters and numbers, and "Cannot use proper names," whatever that actually means. None of those makes any sense with DTMF, where any string is non-uniquely reduced to a string of digits. Passwords are also limited to 20 characters, which is just as arbitrary with DTMF as with anything else.
If you want a phone interface, give me a PIN option. Sure you'll not want me to be able to buy plane tickets with just the PIN, but that should be sufficient to protect user data.