Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Single Sign On

thedailywtf.com

Post reply on HN
Print view View original

11–20 of 73 posts

Re: The Single Sign On

#11

Post by blantonl »

patio11 wrote: post #7

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…

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.

Re: The Single Sign On

#12

Post by fnid2 »

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.

Re: The Single Sign On

#13

Post by GavinB »

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?

What weird dailywtf parallel universe is this?

Re: The Single Sign On

#15

Post by jf »

patio11 wrote: post #7

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…

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.

Re: The Single Sign On

#16

Post by lukev »

patio11 wrote: post #7

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…

I came here to post just this. 2-way SSL is perfect for this scenario, and a hundred times more secure than any of the alternatives.

Re: The Single Sign On

#17

Post by HeyLaughingBoy »

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?

Re: The Single Sign On

#18

Post by Karzyn »

HeyLaughingBoy wrote: post #17

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 t…

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.

Re: The Single Sign On

#19

Post by imgabe »

illumin8 wrote: post #4

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#…

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.

Re: The Single Sign On

#20

Post by nopassrecover »

orangecat wrote: post #3

“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)
Post reply on HN