9 ms·
The Single Sign On
- fnid2 17y agoI don't think it's funny and I don't think either the hospital or the consultants/contractors/employees who built this system are worth their weight in salt. It was a horribly expensive move and had very little benefit to the system or the patients or the hospital. It was a huge waste of money and it is decisions like this that are sending health care costs through the roof. How incompetent must you be to go through all that and find out after months of work and thousands, perhaps tens of thousands, of dollars spent that what you were doing benefited only one person for less than 1 minute a day? It's a really sad state of affairs that this scenario exists. Pathetic really. If I was the hospital, I'd fire the contractors and the stupid person running the system who can't remember a password. These kinds of people end up costing you more and more and more in the long run.
- isleyaardvark 17y agoIt's unfair to blame the consultants when it was entirely the client's project manager's fault. It's the PM's responsibility to figure out how many of her company's employees will use it and whether or not it's worth the cost. There's not a whole lot the consultants could have done, even if they had had the foresight to ask "By the way, is this only going to be for one user?" or "Are you really sure you want to do this?"
- bmm6o 17y agoWell, keep in mind that this is the DailyWTF, so the story has probably been enhanced for your entertainment/outrage. It's rare that you can take a story on the site at face value.
- GavinB 17y agoIs it just me, or did was the annoying sales guy completely right about the technology being possible, able to satisfy the client, and successful in closing a profitable deal for the company? What weird dailywtf parallel universe is this?
- wheaties 17y agoThe WTF is the fact that a single employee would cost a company several tens of thousands of dollars plus several weeks of development time all because that employee didn't want to remember a password.
- deleted 17y ago[deleted]
- orblivion 17y agoWell, it was probably an important employee.
- run4yourlives 17y agoActually, the WTF is that nobody bothered to mention (or ask) that only a single employee used the system.
- gridspy 17y agoThe salesperson did say that there was only a single client... “But we don’t need to change it for everyone,” Craig jumped in, “just one client. Surely, you can do that!”
- Jim72 17y agoOne for all and all for one! I don't know, maybe I would have opted for a enterprise level account with Roboform?
- HeyLaughingBoy 17y agoOK, I'm not a web developer: I do embedded systems and hardware interfacing, so go easy on me :-) Assuming that the hospital network was secure, then why couldn't the system, when receiving a request from that single IP, request a cookie? If the cookie doesn't exist, then that user has never logged in and is then given an identifying, non expiring cookie and from then on is allowed access and is identified? Knowing the hospital's external IP would serve as authentication. I know just enough about web apps to be dangerous, so someone please tell me what's wrong with this idea?
- Karzyn 17y agoI believe that the system you described would allow all users on the hospital system to log in since the system can't check who exactly is requesting the cookie. Plus, once the cookie is distributed it is only associated with the current login attempt so the system cannot know exactly which user it is.
- cookiecaper 17y agoThat's not a problem if you know the end game, which is that only one person in the hospital will ever know about it, but if you assume more than one person in the hospital will need access, you need to provide user-level permissions to prevent patient records from falling into the wrong hands; if you just give everyone in the hospital the exact same level of access, you're exposing a lot of things to a lot of people that shouldn't know about them.
- dkarl 17y agoKnowing the hospital's external IP would serve as authentication. Unless the hospital provides wifi for guests and visitors.
- olegk 17y agoCouldn't they just let the browser remember the password?
- pavel_lishin 17y agoYeah, but then the user would have to type the password in once. Apparently, even this was too much.
- nathanh 17y agoThose of you with sales teams, what guidance do you have about sales people promising features that don't exist without getting input from the rest of your team?
- jonknee 17y agoFine as long as it's for a lot of cash. If the customer is willing to pay for it, I'm happy to jump through crazy hoops.
- cookiecaper 17y agoReally? What if the client demands that your application is in "3D holograph" and won't accept anything that doesn't pop out of the monitor without any special assistance from the user? You're OK with selling that even though, no matter how much money they produce, it would take years and years of development, and may not even be possible until some other foundational technical breakthroughs occur? Please don't take this too literally and tell me all the reasons why 3D holograph is feasible, you get the point.
- ryanelkins 17y agoFor enough money upfront I'll get started today. For something really out of the norm a good salesperson should have gotten the customer to agree to an amount of money that would make it well worth it, whatever the task may be. I think for any outrageous example you come up with the cost will bring the customer back to reality.
- cookiecaper 17y agoIt's dishonest to pitch it as a product you're selling when the technology to build it doesn't even exist yet. You can't say "Sure, we can do that for xxx million dollars and ten years", because you don't know if you'll have it all figured out even after xxx million and ten years, because nobody knows what would actually be required to produce that product. There may be some theory, but if that theory is erroneous for your application and you placed bets on it, you're screwed. You have to pitch as a research investment. If a company wants to give you money for that kind of research, that's great, but you really need to make clear that it's not something you can just go and implement even if you have an infinite supply of money.
- ShabbyDoo 17y ago"And not just followed, but followed, tested, certified, re-certified, and double-tested." HIPAA doesn't prescribe specific technological mechanisms or official certifications. IIRC, a username and password assigned to an individual user is sufficient. I believe there are some audit-ability (who saw/wrote what) requirements as well, but it's been a few years since I dealt with HIPAA. As a user of a system for which inappropriate data access can get you fired, you should be concerned if it does not have strict authentication mechanisms. Sally can blame Bill for having looked at some famous person's medical record. Such snooping is actually is a recurring real problem at major hospitals which treat famous people. The Cleveland Clinic sort of solved it by assigning people like Drew Carey (widely known to be a Clinic patient) a pseudonym. All electronic records are under that name, so most people looking wouldn't realize who the patient was. A VIP office handled billing reconciliation. It's a cute security through obscurity mechanism although it's probably well known on which dates Drew visited the Clinc and which physicians likely saw him.
- bmelton 17y agoOddly enough, I've actually DONE this with off the shelf products, and didn't really consider it that big a deal at all. The only thing that needed modification was the app I was writing that needed federated access to. If the company is using a recent Active Directory, it's a snap to set up OpenSSO within their environment to consume Kerberos tokens to authenticate the user (in a browser) via passwordless login. From there, you can configure OpenSSO to federate authentication by providing your site a SAML token, which, when consumed for authentication, means that the only thing you really have to worry about is authorization -- e.g., what a given user can do from within your application. One of my best friends is a developer who often cries 'impossible', only to brilliantly solve whatever problem a week later, usually with some fairly creative thinking, but I've always considered that his one biggest downfall -- crying wolf. That said, I certainly get that if you're an app developer for a given product, the work that was sold was well out of scope.
- pyre 17y agoIf the company is using a recent Active Directory, it's a snap to set up OpenSSO within their environment to consume Kerberos tokens to authenticate the user (in a browser) via passwordless login. From there, you can configure OpenSSO to federate authentication by providing your site a SAML token, which, when consumed for authentication, means that the only thing you really have to worry about is authorization -- e.g., what a given user can do from within your application. You're forgetting that the client's IT people thought that VPN was 'inherently insecure.' What makes you think that they would install this when they would not install a VPN?
- bmelton 17y agoHonestly, it sounds like the software they custom-developed to act in that role was a knockoff of the basic functionality. The flip side is that OpenSSO uses in-built Kerberos encryption, and generates token-based session headers that contain zero sensitive information. Honestly, you may well have a point, in that the customer may well have only been receptive to the chosen solution because it was custom-developed, but I was mostly balking at the developer's initial reaction of 'impossible'. Not only is it not impossible, it isn't hard to do, and certainly didn't require reinventing the wheel when a perfectly adequate solution exists that would not only have worked well, but worked for de-passwordifying OTHER web services as well (potentially).
- orangecat 17y ago“But we don’t need to change it for everyone,” Craig jumped in, “just one client. Surely, you can do that!” That's probably the most frustrating thing I hear from non-technical people, because they really think they're making it easier. Sadly Kolmogorov complexity is not yet a required course in schools.
- nopassrecover 17y agoCan you elaborate on Kolmogorov complexity and its relevance to someone who has not encountered the term before? (I have wikied it: http://en.wikipedia.org/wiki/Kolmogorov_complexity http://en.wikipedia.org/wiki/Kolmogorov_complexity but sleep deprivation may be hindering my ability to spot the link)
- tel 17y agoKolmogorov Complexity relates to the idea that you can use some kind of computer to encapsulate repeating patterns. When you do this, you have to store the data of your program somewhere and its size relates (sort of) to abstractly just how complex the problem was. It's also equivalent to Minimum Message Length, so looking into that might help. Roughly, the relevance remains the same if you just remove "Kolmogorov" from the op's statement. The manager doesn't understand that inventing a whole new solution is complex no matter how many or few people use it. Which isn't strictly true, but it's definitely a good rule of thumb.
- gjm11 17y agoTo someone who doesn't understand what's going on, it may seem simpler to make something work for one person than to make it work for lots of people; but in fact the version that works for lots of people may be no less simple. (It may even be simpler, if it's necessary to put in special-case testing to make sure that only one person can use it.) From an implementer's perspective, the right measure of the complexity of a system is "how much code does it take to implement?" (which is more or less Kolmogorov complexity) rather than "how many things can it do?" or "how wide is its range of possible behaviours?". A few other remarks on Kolmogorov complexity: 1. "Random" is often best understood as "of high Kolmogorov complexity": a sequence of numbers is random if there's no way to generate it that really saves anything over listing all the numbers; no pattern that makes it predictable. (In practice, what you usually care about is that certain restricted kinds of pattern don't occur, which is kinda like a version of Kolmogorov complexity where you're limited to using programs in a language that isn't Turing-complete.) 2. If you apply Ockham's razor in the form "prefer hypotheses with lower Kolmogorov complexity" together with Bayes' theorem, you get something that in a certain (rather artificial) sense is as effective a problem solver as anything mechanized can be. Unfortunately it's unimplementable in practice, because ... 3. It's more or less always impossible to determine for sure what the Kolmogorov complexity of anything is. (Because to be able to do that you'd need to be able to answer the question "do these two programs do the same thing or not?", and that's equivalent to the halting problem.) 4. (This is controversial, but it's my opinion and that of at least some other contributors here.) When assessing (e.g.) scientific hypotheses for "simplicity" or "parsimony", something like Kolmogorov complexity is the Right Way to understand (un)simplicity; failure to appreciate this is, e.g., what makes some people dislike the "many worlds" interpretation of quantum mechanics on the grounds of extravagance, or think that "God did it" is a useful explanation for otherwise-surprising features of the universe.
- illumin8 17y agoHilarious, and yet, sadly, this must be true. I've been asked countless times by end users why they must login to applications. I think the general population of business (read: average) computer users honestly thinks that passwords should not be required for accessing any information. These are the same type of users that have post-it notes with passwords attached to their monitors and probably write their ATM PIN# on the back of their debit cards.
- imgabe 17y agoI think people get the need for a password, it's just that for the average office job, you have something like at least half a dozen different passwords, with different complexity requirements and different reset schedules. At work I have different passwords for: Windows login Expense report system Timesheet system Employee information system (where I can view my pay stub, w2, etc) 401(k) provider Insurance provider Various ftp or other file sharing services for shuttling data back and forth with clients. And that's in addition to the all the normal passwords I have for personal stuff. What's worse is most of that is used infrequently so the login process never has a chance to sink into muscle memory. The login process is pretty much forgot/reset password every time I use it.
- shade 17y agoI run into this a lot and it's quite frustrating, so I just gave up and started keeping everything in a Keepass database. Works well enough.
- ghfdrvtsyup 17y agoIf you have that many passwords, why not make some sort of base password and then riff off of the base password for everything that needs access (and have a mental sequence for when an item needs a reset)? If your base password is at the highest complexity requirement, the only thing you need to remember is the individual sequences. I do this for my passwords and it's been working for me for years ...
- imgabe 17y ago
- kemiller 17y agoThat was actually a pretty clever solution he came up with. I didn't see the punchline coming.
- frankus 17y agoI only caught the double-entendre in the title after reading the article.
- deleted 17y ago[deleted]
- imp 17y agoI only caught the double-entendre after reading your comment.
- blantonl 17y agoactually, it is a pretty standard solution to these types of problems - it's called Federated Identity Management. There are a number of standards in place all supported by a number of different vendors that provides this type of functionality. SAML and WS-Security are two that come to mind. But I'm in perfect agreement on the punchline, that was awesome.
- Herring 17y agoHang on. If (s)he hates remembering passwords, why not slap on something biometric on top of the normal login process?
- jaredhansen 17y agoThis is a perfect example of why it's important to understand not just what your client is asking for, but why they think they need it. The same lesson goes at least as much, imho, for negotiation - I used to see this all the time at my last job. We'd be negotiating a deal with some counterparty, and they would ask for something completely unnecessary and completely unpleasant (for our side). Sometimes it was just a negotiating ploy so they would have an ask to drop in exchange for something they wanted more, but often as not they just hadn't thought about whether or not they really needed Onerous Provision X. And if instead of fighting over Onerous Provision X you tried to figure out why the other side thought they needed it, and then tried to address that need in some other way, the whole thing went a lot more smoothly, you usually didn't need to give them Onerous Provision X, and everybody walked away feeling like they got what they wanted. The point of which rambling story, I guess, is that in spite of the linked piece being presented as Idiot Client Asking for Dumb Things, the real lesson is that half the time a ridiculous request is actually just an opportunity to meet the underlying need in a better way.
- patio11 17y agoThis situation is virtually made for client-side certificates: 1) You won't need passwords beyond whatever it takes to log in locally. 2) You can assume the hospital computers are physically secured. (Well, I wouldn't, but apparently they do.) 3) The hospital changes machines very infrequently and probably wants a human in the loop every time a machine changes. 4) You can have certificate generation and registration get handled by the on-site IT staff. It is once in a blue moon, and makes them feel like they're not getting paid 6 figures to clear paper jams and reboot Windows. 5) You can mumble any sort of cryptographic magic to scare away people who know just enough about security to be dangerous.
- jf 17y agoI really would love to use client-side certificates everywhere. It's just too much of a pain in the ass to do so. Off the top of my head: - Generating client-side certificates is expensive or a pain in the ass. - Every browser deals with client-side certificates differently. Some give scary warnings, etc. - Firefox and IE can generate keys locally and send a CSR to you, but they do it differently. Safari can't even generate keys locally. I really wish that the state of client-side certificates was better than it is. I look forward to the day when I can easily build services that use client-side certificates.
- washingtondc 17y agoIt's not hard to generate a certificate request. While Firefox and IE may use different routines to do a local key generation, it's certainly not difficult. The scary warnings you're talking about come up if you're connecting to an "untrusted" site - who's SSL server certificate isn't signed by a known, trusted root CA. It's certainly the best solution to this problem.
- jf 17y agoYes, generating a certificate request isn't hard. Maintaining a CA is annoying at best. Do you have a link to a site that describes how to do local key generation in Firefox and IE? Maybe I was just looking in the wrong places? The scary warnings I was talking about are not the "untrusted" site warnings, they are the warnings you get after the remote SSL server times out. I guess this can happen after a few hours, depending on the server. Yes, it's the best solution to this problem, but it's still a major pain in the ass.
- polymath21 17y agoGreat article, and I'm also not surprised, I had to work with a doctor once and basically took care of all her IT tasks because she was COMPLETELY technology averse and also forgot her logins all the time. I wasn't sure if this was normal of medical professionals, but this article just further reinforced that image.
- noonespecial 17y agoOne lesson (relearned) is to never say anything is impossible to do with a general purpose computer unless it actually violates a law of physics. (Even then, have a think about if you can achieve the same goal without said violation) With computers, the answer is always yes, but you might not always like the bill at the end.
- cliveholloway 17y ago1) add a cert signing server that you control to the client's browser, 2) install a self signed SSL cert in the client's browser, 3) done. (assumes over https, which for HIPAA stuff should be a given)
- bricestacey 17y ago"After going back to the drawing board, Gerald came up with another idea: configure the firewall proxy server on the client’s side to add a custom HTTP header (X-Forwarded-For) that included the original IP address. That idea went over just about as well: HTTP headers could be forged, and a malicious employee inside of the company could hack in too easily." I believe this is a perfectly acceptable solution, except they should strip any existing X-Forwarded-For headers sent by a client and only auto-login users originating from the NAT. Problem solved... I think?