181–190 of 221 posts
What does this tell us about BoA's password storage?
Earlier quoted context omitted.
This may well be the most elegant way to solve a complex problem. It seems to me that these silly, arbitrary restrictions on password lengths and contents are far too common to explain or excuse in this way. The full list of JetBlue's password restrictions looks very much like the restrictions at a zillion other sites. The "no Q or Z" thing is strikingly weird, but its probably less harmful than the (very common) low…
Sure, maybe. But you're guessing at how the system works and how it's used and what the constraints are... Maybe Jetblue's developers a bunch of lazy dummies who couldn't think up the solution in your comment... But my experience suggests to me that they're much more likely to be perfectly competent and that there's simply more to the problem than is apparent from the outside.
I was attempting to come up with a layer that would paper over any constraints of the underlying system, but you're right that I'm guessing.
Maybe Jetblue's developers a bunch of lazy dummies...
I would never be as harsh as that. I would guess that this sort of thing is a matter of institutional culture. Nonsensical password rules are extremely common. The organizations responsible are doubtless full of individuals who know they're not optimal, but fixing the password rules is never on the top of anyone's priority list. And once you've gone live with the bad password arrangement (as you well might under schedule/budget pressure), it becomes hugely more difficult to change things.
Earlier quoted context omitted.
This may well be the most elegant way to solve a complex problem. It seems to me that these silly, arbitrary restrictions on password lengths and contents are far too common to explain or excuse in this way. The full list of JetBlue's password restrictions looks very much like the restrictions at a zillion other sites. The "no Q or Z" thing is strikingly weird, but its probably less harmful than the (very common) low…
Given the other strange, arbitrary restrictions we've seen in the wild over the years — no "special" characters, no longer than 12 characters, ad nauseum — my bet is that someone has it in his head that restricting the usable character set even further will somehow improve security. How, exactly, a rule like this improves security, I'm sure he cannot say, at least in a sensical way. Most of the time, these weird rule…
Earlier quoted context omitted.
Less of a coincidence when flying was expensive enough to be reserved for the "jet set".
No doubt. Interestingly, this meeting didn't happen on a jet and probably predates the term "jet set", as the first jet airliner had only entered service the year before. The IBM salesman thinks it might have been a DC-6: http://conservancy.umn.edu/bitstream/11299/107637/1/oh034rbs... Interesting little note from that: "I learned later that he would be sitting in his office in New York and he'd suddenly wonder how th…
Earlier quoted context omitted.
> I doubt many company presidents are taking that sort of approach anymore. That's why they buy a jet with company money now.
Sure, but how often do they just decide, on a lark, to go check out how operations are going at one of their sites on the other side of the country?
> Early in his tenure, Cook was told of a problem with one of Apple's Chinese suppliers. "This is really bad", he said. "Someone should really be in China driving this." 30 minutes later he looked at an operations executive sitting at the table and unemotionally asked, "What are you still doing here?" The executive stood up, drove directly to San Francisco Airport, and bought a ticket to China.
Earlier quoted context omitted.
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)
" then these processes have to be modernized" 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?"
The target breach would be nothing compared to the breach of a system in use for 60 years.
Actually this kind of gives me an idea: what if modern systems decided to just tell people they can't use "p" so that people stop using the word "password" or variants as their password. Hell, for that matter, tell users they can't use vowels so they can't make words. They might do leet speak, or whatever which is pretty easy to crack given time, but it stops things like password re-use attacks (people less likely to…
You've reminded me of something I found interesting regarding passwords in China. Often, faced with minimum password standards, a user will choose the first Romanised (Pinyin - used for keyboard input as well as phoneticisation) letter of a word in a phrase, an example being 我看懂中文你呢？ which is Romanised as 'wo neng kan dong zhong wen ni ne?' or to take the first letter of each word 'wnkdzwnn?' (This phrase, meaning 'I…
Earlier quoted context omitted.
> I doubt many company presidents are taking that sort of approach anymore. That's why they buy a jet with company money now.
Sure, but how often do they just decide, on a lark, to go check out how operations are going at one of their sites on the other side of the country?
Earlier quoted context omitted.
so, they have a requirement to maintain compatibility with telephone password input, but require an uppercase character as well? it does not make any sense. this is incompetent developers in a dysfunctional environment. there is no good light anyone can throw at it. and no, having the system live since the 50s is not a good excuse. it is certainly not the same system, for obvious reason.
That makes perfect sense. 'A' and 'a' are both on the 2 key, along with 'b', 'c', 'B', and 'C'.
As several people have noted, the Q/Z restriction likely arises from inputting passwords from a telephone keypad. What I haven't seen is a statement as to why this would have been a problem. The reason is that Q and Z were mapped inconsistently across various phone keypads. The present convention of PQRS on 7 and WXYZ on 9 wasn't settled on until fairly late in the game, and as noted, the airline reservation system,…
If there's a mechanism for specifying case on the phone, there can be a mechanism for specifying Q and Z unambiguously. I certainly have used VM systems that explicitly told me to "use 7 to represent Q and 9 to represent Z."
A contractual requirement is one possibility that could explain it, but my suspicion is rather that some legacy code in the system uses Q and Z as special escape characters or delimiters (because of their absence on the phone dial), and it's not worth the cost to try to fix the ancient code (or do all the testing necessary to be confident of deploying a workaround).