The Single Sign On
thedailywtf.com
thedailywtf.com
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.
Systems Management vendors love to sell software distribution products to help reduce the distribution requirements for client side certs, but in the end most folks will balk at the price and end up resorting to the sneaker-net approach.
I don't know why they wanted to go ip-based or even bother with cookies since AD queries are practically free.
In ASP.net with all the builtin integrations for AD that's a one day project.
If you want to keep it the licensing is simple - per administrator, regardless of the number of systems that you manage.
Check it out.
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.
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.
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.
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.
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.
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.
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.
Coming across AIXI was what got me interested in algorithmic information theory. It is indeed useless in it's "pure" form, but there's a variation using Monte Carlo search that apparently does pretty well: http://arxiv.org/abs/0909.0801
(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.
Yes. In fact after reading the Less Wrong quantum physics sequence (http://lesswrong.com/lw/r5/the_quantum_physics_sequence/), I find that "the wavefunction collapsed" and "God did it" are remarkably similar statements.
int main(int argc, char** argv) {
return 1;
}
Your general point is very much correct, though. A clearer-cut application: In general, one cannot prove that a program does what it's supposed to; but if doing that is important, "all" you have to do is write it in a way that makes a correctness proof possible.
The link with Kolmogorov is, I believe, that each piece added moves the set away from being simpler.
First time I read about Kolmogorov, hopefully I got it right. Anyway my first paragraph is true!
From that perspective implementing a new login process for "just one client" is worse than changing it for everyone, because it increases the size of the program's description. The revised software must describe the existing login process, the new process, and the logic for deciding which clients use which process. Whereas changing it for everyone requires only describing the new process, and allows you to eliminate the description of the previous process.
What weird dailywtf parallel universe is this?
“But we don’t need to change it for everyone,” Craig jumped in, “just one client. Surely, you can do that!”
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.
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.
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.
I do this for my passwords and it's been working for me for years ...
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.
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?
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).
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.
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?
Unless the hospital provides wifi for guests and visitors.
Please don't take this too literally and tell me all the reasons why 3D holograph is feasible, you get the point.
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.
So basically the sales guy can probe the customer with ideas, but can't commit.
With computers, the answer is always yes, but you might not always like the bill at the end.
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?
(assumes over https, which for HIPAA stuff should be a given)
I don't know, maybe I would have opted for a enterprise level account with Roboform?