6 ms·
I'd caution against making assumptions about the competence of the developers based only what you can see from the outside. More likely than not there are good
by eli 13y ago
I'd caution against making assumptions about the competence of the developers based only what you can see from the outside. More likely than not there are good reasons to maintain interoperability with legacy systems. This may well be the most elegant way to solve a complex problem.
I've certainly written my share of code that would look weird to an outsider who didn't know the backstory and the constraints and the evolution.
- mikeash 13y agoIn this case, a legacy system (Sabre) whose origins predate the integrated circuit. I'm sure a lot has changed since then, but it's a bit scary to wonder what hasn't.
- eli 13y agoI don't find that scary. I think it's a testament to the original architects and to the people who maintain it.
- SnakeDoc 13y agoIt's engineering thoughts like this that continue the proliferation of terrible, and insecure login systems.
- eddieroger 13y agoI'm not sure about that. Sabre is an extremely (assumption) functional tool in an extremely niche market. That makes the barrier to enter it very high, and the barrier to rewrite equally so. Underneath the covers it could be a real piece hung together by duct tape and vacuum tubes, but why rewrite it if it's working and keeping planes in the air?
- fennecfoxen 13y agoBecause OMG HACKERS. Seriously, why do we have any security on anything?
- Alupis 13y agoIt's 2014. Passwords need to be treated as a serious matter. Legacy system or not, there is no good reason to reduce keyspace. As others have mentioned, this is a sign that passwords are being made compatible with old phones without these letters available... and likely the passwords being reduced to numbers before storage. The prohibition of special characters also seems to corroborate this. Furthermore, the poster below who showed screenshots of being emailed their password indicates JetBlue is storing passwords either in plain-text, or encrypting them (both just as bad), instead of properly cryptographically hashing before storage.
- growupkids 13y agoOr emailing them before they hash them.
- cbsmith 13y agoHonestly, if you add one extra digit/character to the password, that more than compensates for the loss of Q & Z. There are lots of circumstances where being able to work with legacy phone systems effortlessly would be most helpful. If you are taking passwords seriously, this might be the very last thing you worry about.
- zibit 13y agoIt's nice to see these thoughts at the top of the thread. I get tired of hearing people in the security industry constantly smirking at "dump developers". They don't have a clue what it's like to develop real code with deadlines. They point fingers at others and call that an accomplishment.
- coldcode 13y agoI doubt that the passwords come from SABRE. There is a lot of stuff between the front end and SABRE. I expect Jet Blue manages their own systems that only call SABRE internally.
- dredmorbius 13y agoI interviewed with an airline in the past few years for a project involving migrating its reservations and management systems (interesting tidbit: both maintenance and reservations were tied to the same underlying system). And integration with SABRE was very much a part of the job req. I passed largely as it seemed that there were some significant organizational issues and wrestling with 60 year old computer systems stopped being my definition of fun a while ago. There were some glitches in the rollout but they got things running by and by.
- Lagged2Death 13y agoThis 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 maximum length restriction, for example. Maybe I'm out of my depth here, but: You're generally supposed to run naked user-chosen passwords through some key-stretching hash anyway. That offers the chance to do away with many of these common restrictions from the user's point of view, even if you can't change the capabilities of the old systems underneath. Feed the password through a hash, run the hash result through a filter that expresses the result in the required character set. Now you've got a password the old system can store. The user's chosen password can be arbitrarily long, it can contain any character, and every character of that user-chosen password will effect the "real" password in the old system. Every real password will be the maximum size the old system can store.
- eli 13y agoSure, 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.
- chavesn 13y agoThat's quite generous of you. I don't think there's any more reason to assume they are competent than to assume they aren't. The fact is that this sucks for the user. It's also a pretty safe bet to say that there are lots of developers putting code into use solving problems outside their competency. You may not want to assume this evidence makes them terrible developers, but that doesn't make the inverse any more likely, either.
- eli 13y ago
- deleted 13y ago[deleted]
- lectrick 13y agoNo. If there is a bizarre password restriction like this, it is almost certainly because they are storing the password in cleartext somewhere (bad) or because they expect users to be able to enter the password in via a telephone keypad, which vastly reduces the number of possible combinations since every number substitutes for 3-4 letters (also bad).
- jtheory 13y ago> or because they expect users to be able to enter the password in via a telephone keypad, which vastly reduces the number of possible combinations since every number substitutes for 3-4 letters (also bad). Not so much as you may assume. I'd bet (not with much money, admittedly) that you can't get into the web interface with a telephone-digit variant of your password. I'm not sure where in their architecture phone-keypad-compatibility lies, but it's quite possibly not even in any user-facing system. In that case, the security of your password is not much reduced -- only if someone has access to that telephone-access system, and can do something bad with it.
- ateeqs 13y agoI suspect that this is the likely answer here, since old telephone keypads did not have Q and Z.
- dredmorbius 13y agoAnd more recent keypads have assigned various characters (particularly Q & Z) inconsistently, as I've posted separately.
- sqrt17 13y agoIntuitively, the reason for forbidding Q and Z could be that those passwords can't be typed in blindly on QWERTZ and QZWERTY keyboards (which you're likely to find if you travel internationally). But then they'd have to be consequent and also forbid Y and maybe A.
- eloisant 13y agoI think it has more to do with Q and Z missing from old phones keyboards.