Oddly 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.
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.
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, 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).
“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.
Can 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 but sleep deprivation may be hindering my ability to spot the link)
Kolmogorov 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.
To 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.
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 ...
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.
3. It's quite possible to determine what the Kolmogorov complexity of something is, it's only impossible to determine what the Kolmogorov complexity of everything is. The halting problem only states that it's impossible to prove whether an arbitrary Turing machine halts. There're many Turing machines that can be proved to halt, some quite easily. For example,
int main(int argc, char** argv) {
return 1;
}
can be proved to halt pretty easily, just looking at the CFG for the program.
I think that even in practice being able to determine the Kolmogorov complexity exactly is very decidedly not the usual case; you need to know that every program shorter than your candidate fails to do the right thing.
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.
In other words, what orangecat meant is that adding more code, even "simple" code, adds complexity to a software project. Adding 50 easy features is equal to adding one heck of complex feature made of 50 sub parts.
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!
Essentially correct. Kolmogorov complexity is the amount of information it takes to fully describe something. A million random bits have high complexity because the shortest way to describe them is to literally list them all. The first million bits of pi have low complexity because they can be generated by an algorithm that takes much less than a million bits to describe. (The algorithm may take a long time to run, but Kolmogorov complexity doesn't care about that).
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.
I think the grandparent meant cyclomatic complexity rather than Kolmogorov complexity. Special-casing a change for one person means at least one more execution branch.
Hilarious, 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.
I 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.
If 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 ...
That's more or less what I do. Not everyone cottons on to this scheme though. With the logins I might use once every 6 months or so, it can still be hard to remember which variation I'm on, especially if it's a "three tries then you're locked out" system.
Well, think of it from their point of view. They don't need a code to open their desk and they don't need a password to open the break-room fridge. And to them, having something go missing from there is scarier than someone logging in as them and looking at numbers.
actually, 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.
This 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.
This 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.
There is one problem with this - now that you've deployed client side certs you now have to implement a software distribution product just to deploy certs to the 100's of computer that require them... or, in this article case, the single computer) :)
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.
Ahh yes, the expensive deployment options. Too true. You can use Admin Arsenal. (www.AdminArsenal.com). It has a 30-day fully functional trial so as a one-time option you can do the cert deployment at no cost. Plus, Admin Arsenal doesn't use agents and is installed on your workstation, so it doesn't require its own server.
If you want to keep it the licensing is simple - per administrator, regardless of the number of systems that you manage.
I 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.
It'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.
Yes, 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.
Great 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.
I 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.
It'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?"
Well, 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.
Is 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?
The 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.
Perhaps the salesperson meant "one client machine" and the programmer assumed that, given the context, meant "one client company." Client can be a rather ambiguous term.
Even a broken clock is wrong twice a day, throw enough darts and you'll hit a bullseye, at least one woman in this bar has gotta be drunk enough, etc. Insert your own folksy analogy here.
The one where DailyWtf submissions are always boiled down and reconstituted into unrecognizable just-so parables that read like the editors of Chicken Soup for the Soul tried to write Malcolm Gladwell articles for InfoWorld.
I wish I could upvote this 10 times. I stopped reading the dailyWTF a long, long time ago because: a) the stories are embellished to the point of being pure fiction, and b) the writer's work is so long-winded that it's just painful to read. I suspect that the author thinks he's being funny.
OK, 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?
I 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.
That'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.
Those 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?
Really? 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.
For 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.
It'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.
No problem as long as it's before the PO. But we won't let a sales guy sign something until we have agreed internally that it can be built and made sure that it makes sense for us.
So basically the sales guy can probe the customer with ideas, but can't commit.
"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.
One 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.
"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.
72 comments
[ 3.7 ms ] story [ 141 ms ] threadIf 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).
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.
http://en.wikipedia.org/wiki/Termination_analysis
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.
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 ...
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.
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.
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.
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.
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!”
I don't know, maybe I would have opted for a enterprise level account with Roboform?
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.
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.
With computers, the answer is always yes, but you might not always like the bill at the end.
(assumes over https, which for HIPAA stuff should be a given)
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?