Should we publish online a shared password for 5000 people?
September 5, 2014 4:37 AM Subscribe
My small company is providing a web service for another organisation. One single username/password combo will be used to access the system. Either -- how should we distribute this combo to the 5,000 tech-illiterate members of the other organisation? Or -- what's a better solution?
I've inherited a situation at a small company, let's call us A.com.
We're building a website for members of another organisation, B.com, to use. It will require username/password login. Nobody else will use the website.
For various reasons that are currently *absolutely* non-negotiable, there will be one single username to access A.com. We will change the password monthly (this is probably a negotiable detail).
B.com already has their own members' areas, which their members access with username/password details that are unique to B.com. We cannot piggy-back on this system, since B.com's site is developed by a third party in Technology Unknown.
The existing plan is for us to regularly change the password, and publish it in the password-protected members' areas of B.com. Yep -- publish the password online in plain-text.
Members of B.com login to B.com, find the current password for A.com, and then go login to A.com.
Problem -- this weakens security. Member IDs for B.com are sequentially issued, and the user-base is very technically non-proficient. The chance of B.com being crackable are probably 100%. That means passwords to A.com can probably be retrieved by a hacker with minimal effort.
Please ignore the obvious: that this is a dumb solution. I've flagged that up already, and I'll be discussing the problems in detail with the boss. As I say, I've inherited this, and I need to fix it.
There is zero budget here. And I mean zero. Purchasing software or skills is not an option, no matter how cheap.
Our website is hosted by a 3rd party who seem averagely proficient in Zend, PHP, Wordpress. I've not been amazingly impressed by their technical chops so far, but they seem like nice guys.
We're doing a likelihood vs damage analysis at the moment, and I'm recommending a mitigation plan if A.com does indeed get compromised.
I've thought about password management; identity authority systems; etc etc -- none of this is feasible. Beyond ripping out the system described, and implementing a bog-standard username/password login of our own, I can't see what else to do.
Any thoughts most gratefully received. Thanks!
I've inherited a situation at a small company, let's call us A.com.
We're building a website for members of another organisation, B.com, to use. It will require username/password login. Nobody else will use the website.
For various reasons that are currently *absolutely* non-negotiable, there will be one single username to access A.com. We will change the password monthly (this is probably a negotiable detail).
B.com already has their own members' areas, which their members access with username/password details that are unique to B.com. We cannot piggy-back on this system, since B.com's site is developed by a third party in Technology Unknown.
The existing plan is for us to regularly change the password, and publish it in the password-protected members' areas of B.com. Yep -- publish the password online in plain-text.
Members of B.com login to B.com, find the current password for A.com, and then go login to A.com.
Problem -- this weakens security. Member IDs for B.com are sequentially issued, and the user-base is very technically non-proficient. The chance of B.com being crackable are probably 100%. That means passwords to A.com can probably be retrieved by a hacker with minimal effort.
Please ignore the obvious: that this is a dumb solution. I've flagged that up already, and I'll be discussing the problems in detail with the boss. As I say, I've inherited this, and I need to fix it.
There is zero budget here. And I mean zero. Purchasing software or skills is not an option, no matter how cheap.
Our website is hosted by a 3rd party who seem averagely proficient in Zend, PHP, Wordpress. I've not been amazingly impressed by their technical chops so far, but they seem like nice guys.
We're doing a likelihood vs damage analysis at the moment, and I'm recommending a mitigation plan if A.com does indeed get compromised.
I've thought about password management; identity authority systems; etc etc -- none of this is feasible. Beyond ripping out the system described, and implementing a bog-standard username/password login of our own, I can't see what else to do.
Any thoughts most gratefully received. Thanks!
Is it a requirement that everyone on B.com use the same password, too?
Say, if this was possible:
Username: global_whatever
Password:[actual_username][actual_password]
and you showed each member a different 'password' that's actually some kind of fixed length globally unique identifier concatenated with a password?
posted by Ashlyth at 4:52 AM on September 5, 2014
Say, if this was possible:
Username: global_whatever
Password:[actual_username][actual_password]
and you showed each member a different 'password' that's actually some kind of fixed length globally unique identifier concatenated with a password?
posted by Ashlyth at 4:52 AM on September 5, 2014
I guess my big question would be, what's going on A.com? Is it something where there are really heavy penalties involved if the wrong person gets access to it? I mean, if you're talking about HIPAA data or really sensitive financial stuff or people's social security numbers, I would absolutely go to bat for this not being an acceptable solution under any circumstances. If the site is a place for people to, I don't know, book conference rooms, and it's down for a couple days at some point because spammers got in and everybody has to go back to calling Tracy to figure out if the conference room is free, it's not that this isn't a dumb idea but the harm involved is different. I used to be a member of a wiki that had a single editing password for everybody with edit access, and it was a relatively short dictionary word, and every now and then there was a problem, but we'd revert the changes and it just wasn't worth more effort than that. The value of what you're trying to protect is really relevant here.
posted by Sequence at 4:53 AM on September 5, 2014 [11 favorites]
posted by Sequence at 4:53 AM on September 5, 2014 [11 favorites]
I was going to suggest what Ashlyth suggested. Maybe you could concatenate, say, the first 4 digits of their payroll number (i.e. something on a physical document that only they can access) plus the year they were born (or something similar that they can easily remember).
Another suggestion with regards to the payroll number: I seem to remember that the banks would ask you for 4 random digits from a password that you set up (first,third, fourth and last for example). Could that be implemented using a unique identifier such as a payroll number?
posted by mukade at 5:00 AM on September 5, 2014
Another suggestion with regards to the payroll number: I seem to remember that the banks would ask you for 4 random digits from a password that you set up (first,third, fourth and last for example). Could that be implemented using a unique identifier such as a payroll number?
posted by mukade at 5:00 AM on September 5, 2014
A better solution than just accepting the situation is to de-risk the web service by removing anything sensitive, and to add on whatever controls you're able to apply - for example, by only allowing computers from the IP address range of your client organisation to reach the login page.
Nothing will be even approaching fool proof and you'll always be hamstrung by the shared login. It will mean that any sort of granular access control is impossible, you'll potentially have to change the password whenever one of those 5,000 people within B.com leave under any sort of cloud, and you'll struggle to trace any actions back to an individual or prove any wrongdoing in the event of misuse of the information on the site.
If they haven't done so already, you should really get B.com to sign off on accepting this risk as part of the service. It would not be good if they only find this out after an incident occurs.
posted by dvrmmr at 5:16 AM on September 5, 2014 [3 favorites]
Nothing will be even approaching fool proof and you'll always be hamstrung by the shared login. It will mean that any sort of granular access control is impossible, you'll potentially have to change the password whenever one of those 5,000 people within B.com leave under any sort of cloud, and you'll struggle to trace any actions back to an individual or prove any wrongdoing in the event of misuse of the information on the site.
If they haven't done so already, you should really get B.com to sign off on accepting this risk as part of the service. It would not be good if they only find this out after an incident occurs.
posted by dvrmmr at 5:16 AM on September 5, 2014 [3 favorites]
This is basically the same as making A.com a public website. So you might as well just make A.com a public website, and not allow users to do anything to it that members of the public can't do, and warn everyone that anything posted to A.com will be accessible to anyone who uses the internet. Because functionally, that's true, under your "post a single password that anyone can use without any sort of authentication or identification" plan.
posted by decathecting at 5:42 AM on September 5, 2014 [8 favorites]
posted by decathecting at 5:42 AM on September 5, 2014 [8 favorites]
What The Michael The said. I hate answering askmes with answers that go against absolute requirements, but there is essentially no purpose in you distributing this password at all. It's a false sense of security.
If you're going to go this route, you should insist on having no password, just to make it absolutely clear to everyone that the site is not protected in any way.
posted by dmd at 5:43 AM on September 5, 2014 [8 favorites]
If you're going to go this route, you should insist on having no password, just to make it absolutely clear to everyone that the site is not protected in any way.
posted by dmd at 5:43 AM on September 5, 2014 [8 favorites]
Even technically deficient people know how to use email and phone. Could you collect their emails or mobile phone numbers and use the distribution list to blast the password?
posted by rada at 5:46 AM on September 5, 2014
posted by rada at 5:46 AM on September 5, 2014
Also if there is anything remotely useful one disgruntled employee could also take the whole thing down and there would not be a identifier.
If there is time to fix the site it should be trivial to a least set up group passwords limited to a smaller number of people if you must go the group password route.
Money wise setting up some sort of free open source database to store hashes shouldn't be difficult or costly . And once it is set up it is automated so no tinkering required.
posted by AlexiaSky at 5:56 AM on September 5, 2014
If there is time to fix the site it should be trivial to a least set up group passwords limited to a smaller number of people if you must go the group password route.
Money wise setting up some sort of free open source database to store hashes shouldn't be difficult or costly . And once it is set up it is automated so no tinkering required.
posted by AlexiaSky at 5:56 AM on September 5, 2014
Seriously, this is a public website. A password and login shared by 5000 people is NOT a security measure, even if you don't host in plain text on another website. You need to make the lack of security absolutely clear to B.com. They need to make the lack of security absolutely clear to their employees, clients, and vendors.
posted by mskyle at 5:57 AM on September 5, 2014
posted by mskyle at 5:57 AM on September 5, 2014
Best answer: Agreed with everyone. This is sort of like using velcro to lock the door to a bank. Sure, it is "better than nothing" but barely, and anyone with the slightest desire to muck about in the site will have next to no trouble doing so, and you will have no way of tracking who did what. Like others have said, this solution needs to be treated as though there were no protection at all.
Is there anyway to only have the link to the site be accessible by first going through the properly secured, unique username and passworded site, and then put in a check on the new site that will bounce the user to a different "Access not allowed" page if the referrer wasn't that secure site? This isn't a perfect solution, but it may offer at least SOME small amount of extra protection. You may be able to pass along the username of the person logged in so that when changes are made you can at least record that username. Know what I mean?
Since you say you absolutely cannot have people have their own username and password and the solution (everyone use the same one) is basically a total non-solution and rife with risks, you better make damned sure you have a very well laid out document that B.com has to sign where they acknowledge the immense security risks and inadequacy of any sort of protection in this plan, and that they agree to do it anyway. If they insist on going this route then you need to protect yourself when bad things start happening.
posted by PuppetMcSockerson at 6:04 AM on September 5, 2014 [2 favorites]
Is there anyway to only have the link to the site be accessible by first going through the properly secured, unique username and passworded site, and then put in a check on the new site that will bounce the user to a different "Access not allowed" page if the referrer wasn't that secure site? This isn't a perfect solution, but it may offer at least SOME small amount of extra protection. You may be able to pass along the username of the person logged in so that when changes are made you can at least record that username. Know what I mean?
Since you say you absolutely cannot have people have their own username and password and the solution (everyone use the same one) is basically a total non-solution and rife with risks, you better make damned sure you have a very well laid out document that B.com has to sign where they acknowledge the immense security risks and inadequacy of any sort of protection in this plan, and that they agree to do it anyway. If they insist on going this route then you need to protect yourself when bad things start happening.
posted by PuppetMcSockerson at 6:04 AM on September 5, 2014 [2 favorites]
Does everyone at B have BCorp email addresses? I'd ditch all this username password nonsense if so, and have every connection ask for their email address.
It's at B Corp? Okay, email that account a single use login URL that expires in 30 minutes. When they connect to that URL you an set a cookie that is good for 24 hours or 2h or inactivity or whatever the hell.
It's not fantastic but you require that any penetration be preceded by an email user at B Corp being compromised and you actually can now track per-user connections/violations.
posted by phearlez at 6:07 AM on September 5, 2014
It's at B Corp? Okay, email that account a single use login URL that expires in 30 minutes. When they connect to that URL you an set a cookie that is good for 24 hours or 2h or inactivity or whatever the hell.
It's not fantastic but you require that any penetration be preceded by an email user at B Corp being compromised and you actually can now track per-user connections/violations.
posted by phearlez at 6:07 AM on September 5, 2014
Best answer: As many have said, this is awful. THAT SAID:
Post a link on B.com and check your referrer field to ensure that people are navigating to your site from the location on B.com. It's not perfect, but it's a superior control to just having a uname and pw.
Is B.com a corporation? Restrict the IPs that can access A.com to only coming from B.com's address range.
Is B.com a corporation running windows? Have their IT staff roll out client certificates and trust certs issued by their CA.
Without knowing what is on A.com and what the risk exposure is from disclosure, it's hard for me to recommend further controls or further levers for getting management to budge.
posted by bfranklin at 6:12 AM on September 5, 2014 [1 favorite]
Post a link on B.com and check your referrer field to ensure that people are navigating to your site from the location on B.com. It's not perfect, but it's a superior control to just having a uname and pw.
Is B.com a corporation? Restrict the IPs that can access A.com to only coming from B.com's address range.
Is B.com a corporation running windows? Have their IT staff roll out client certificates and trust certs issued by their CA.
Without knowing what is on A.com and what the risk exposure is from disclosure, it's hard for me to recommend further controls or further levers for getting management to budge.
posted by bfranklin at 6:12 AM on September 5, 2014 [1 favorite]
PuppetMcSockerson's suggestion (which is a good one!) would probably involve setting up a proxy server or using a VPN, which you probably can't do without cooperation from the technical people at B.com, which it sounds like you're not likely to get.
(If B.com is always using A.com from, say, within the B.com building, you could also restrict access to a range of IP addresses, not sure if that would apply here though.)
posted by mskyle at 6:16 AM on September 5, 2014
(If B.com is always using A.com from, say, within the B.com building, you could also restrict access to a range of IP addresses, not sure if that would apply here though.)
posted by mskyle at 6:16 AM on September 5, 2014
It would probably be better to post the current password in the B.com breakroom/reception desk/locker room/whatever rather than on their website.
posted by Rock Steady at 6:38 AM on September 5, 2014
posted by Rock Steady at 6:38 AM on September 5, 2014
Best answer: Use the telephone. Have the password distributed by person-to-person telephone calls using the management structure at the company.
Yes, it's a tiny bit more cumbersome, but it's also encouraging voice-to-voice contact for managers, supervisors, etc. at the company. This helps build personal trust and knowledge of each other, and that's good for security too. There may even be some kind of regular monthly communication happening by phone or in person where this information can be included (NOT e-mail, has to be phone or face-to-face). After the second month, it will be much easier.
This will also have the effect of making all the users think about security one tiny moment every month.
Not everything needs a more technological solution.
You can specify whether it's OK to leave the password on voicemail - I'd suggest not allowing voicemail.
You'll probably want to have password rules that make the password easier to communicate verbally (no "right bracket/parentheses/brace"-type characters). This might mean slightly more crackable passwords, but that's probably the least of your issues here.
posted by amtho at 6:42 AM on September 5, 2014 [1 favorite]
Yes, it's a tiny bit more cumbersome, but it's also encouraging voice-to-voice contact for managers, supervisors, etc. at the company. This helps build personal trust and knowledge of each other, and that's good for security too. There may even be some kind of regular monthly communication happening by phone or in person where this information can be included (NOT e-mail, has to be phone or face-to-face). After the second month, it will be much easier.
This will also have the effect of making all the users think about security one tiny moment every month.
Not everything needs a more technological solution.
You can specify whether it's OK to leave the password on voicemail - I'd suggest not allowing voicemail.
You'll probably want to have password rules that make the password easier to communicate verbally (no "right bracket/parentheses/brace"-type characters). This might mean slightly more crackable passwords, but that's probably the least of your issues here.
posted by amtho at 6:42 AM on September 5, 2014 [1 favorite]
Response by poster: Checking referring website is a great idea, and should be reasonably simple to implement. Many thanks for that, it at least adds a second strip of velcro!
As for all the comments along the "this is AWFUL" and "this is equivalent to zero security" lines -- believe me, I know.
More details below, since some responses suggest good options that are unfortunately not feasible:
A.com has built the service for ourselves, not for B.com. We simply know that our user base will be a subset of B.com's user base, which is the set of all possible valid users. This is because B.com contains 100% of the members of a profession, and A.com is an affiliated organisation within that profession.
We have zero access to things like usernames at B.com so making unique logins for individual users is impossible.
B.com is not an office-based organisation. Members work from home throughout the country. So IP-based restriction is not an option. And unfortunately they don't have email-addresses@B.com which is a shame, since that would simplify things immediately.
posted by ajp at 6:43 AM on September 5, 2014
As for all the comments along the "this is AWFUL" and "this is equivalent to zero security" lines -- believe me, I know.
More details below, since some responses suggest good options that are unfortunately not feasible:
A.com has built the service for ourselves, not for B.com. We simply know that our user base will be a subset of B.com's user base, which is the set of all possible valid users. This is because B.com contains 100% of the members of a profession, and A.com is an affiliated organisation within that profession.
We have zero access to things like usernames at B.com so making unique logins for individual users is impossible.
B.com is not an office-based organisation. Members work from home throughout the country. So IP-based restriction is not an option. And unfortunately they don't have email-addresses@B.com which is a shame, since that would simplify things immediately.
posted by ajp at 6:43 AM on September 5, 2014
Response by poster: Telephone.... a very interesting idea. Without getting into inane detail, it won't work how you describe it. But it does give me a possible other avenue to investigate. Many thanks.
posted by ajp at 6:44 AM on September 5, 2014
posted by ajp at 6:44 AM on September 5, 2014
Best answer: B.com already has their own members' areas, which their members access with username/password details that are unique to B.com. We cannot piggy-back on this system, since B.com's site is developed by a third party in Technology Unknown.
Do they have any service contract with the third party, such that they can do anything at all? Or will this username/password combination just be posted in some CMS by some flunky at B?
If they can do any fairly minor development then - in a somewhat variation on the emailed link concept - they could create the page with the link to your service such that on the server side it does a POST to your site with the user ID. Your site hands back a, say, 5 character token like LSJYC which is good for 30 minutes. They build it into the url http://a.com/bLogin?token=LSJYC
On your side you check incoming folks on that link for referrer if you like and the token's validity.
That way you can secure the POST process other ways. A server username and password, or a public/private key scheme. You can be rigorous about incoming IP which is a little more stringent than the easily duped referrer.
posted by phearlez at 7:15 AM on September 5, 2014
Do they have any service contract with the third party, such that they can do anything at all? Or will this username/password combination just be posted in some CMS by some flunky at B?
If they can do any fairly minor development then - in a somewhat variation on the emailed link concept - they could create the page with the link to your service such that on the server side it does a POST to your site with the user ID. Your site hands back a, say, 5 character token like LSJYC which is good for 30 minutes. They build it into the url http://a.com/bLogin?token=LSJYC
On your side you check incoming folks on that link for referrer if you like and the token's validity.
That way you can secure the POST process other ways. A server username and password, or a public/private key scheme. You can be rigorous about incoming IP which is a little more stringent than the easily duped referrer.
posted by phearlez at 7:15 AM on September 5, 2014
Response by poster: Oh and since it was asked, yes the data on A.com will potentially be valuable/damaging.
posted by ajp at 7:17 AM on September 5, 2014
posted by ajp at 7:17 AM on September 5, 2014
Response by poster: @phearlez Thank you. I was thinking of some sort of asymmetric key stuff, but hadn't got into the detail of how to implement it. And the expiration idea (also mentioned by others) is a great addition. This is most definitely worth looking at.
posted by ajp at 7:19 AM on September 5, 2014
posted by ajp at 7:19 AM on September 5, 2014
Response by poster: Since it's been asked... both websites for both companies are maintained by different third parties. The third parties a small-fry, and there are costs associated with getting them to do work. These two third parties have never collaborated directly with each other.
posted by ajp at 7:22 AM on September 5, 2014
posted by ajp at 7:22 AM on September 5, 2014
Wow, you're screwed. I'd say that the people who are talking CYA have the right of it. As you already know, this essentially is a public website, and so what they're doing is contemplating publishing their "potentially... valuable/damaging" information to the world. Your issue at this point is self-protection---can you keep you, and to the extent possible, whatever company you work for (it's not terribly clear) from getting burned by the fire that will undoubtedly result when this stuff gets cracked.
I'd go so far as to say that you might see if there's budget for your company to lawyer up here (maybe no tech budget doesn't mean no legal budget), or maybe a lawyer who will work pro bono in preparing some CYA for you. That, and making sure the problems with this system are so incredibly heavily documented that nobody can ever blame you for being dragged, kicking and screaming, into implementing this disaster.
posted by paultopia at 7:29 AM on September 5, 2014
I'd go so far as to say that you might see if there's budget for your company to lawyer up here (maybe no tech budget doesn't mean no legal budget), or maybe a lawyer who will work pro bono in preparing some CYA for you. That, and making sure the problems with this system are so incredibly heavily documented that nobody can ever blame you for being dragged, kicking and screaming, into implementing this disaster.
posted by paultopia at 7:29 AM on September 5, 2014
Response by poster: Based on the token-built-into-URL idea, I'm thinking of some sort of symmetric encryption method might work here. Let's see...
A.com and B.com secretly share a private key.
User logs into B.com which uses the private key to generate a link of the format:
http://a.com/login/?hash
The hash contains data in some pre-determined format, such as ddddmmyyhhmmss&userID all encrypted using the private key. This will make all hashes unique and non-repeating.
A.com then permits the use of that hash for a fixed time period. Any repeated or out-of-date hashes are rejected, and their use could be recorded and monitored.
Does that sound bonkers?
This obviates the need for a username/password login directly on A.com, which may or may not be acceptable by my superiors. But at least I've got options.
Many thanks again. Thinking this through with your suggestions has been invaluable.
posted by ajp at 7:39 AM on September 5, 2014
A.com and B.com secretly share a private key.
User logs into B.com which uses the private key to generate a link of the format:
http://a.com/login/?hash
The hash contains data in some pre-determined format, such as ddddmmyyhhmmss&userID all encrypted using the private key. This will make all hashes unique and non-repeating.
A.com then permits the use of that hash for a fixed time period. Any repeated or out-of-date hashes are rejected, and their use could be recorded and monitored.
Does that sound bonkers?
This obviates the need for a username/password login directly on A.com, which may or may not be acceptable by my superiors. But at least I've got options.
Many thanks again. Thinking this through with your suggestions has been invaluable.
posted by ajp at 7:39 AM on September 5, 2014
Response by poster: @paultopia I work at A.com. Everyone in A.com and B.com is non-techy. I think they consider the likelihood of a hack to be low, and the potential damage to be medium. I personally rate both as "high", putting this project squarely in the red in my opinion.
A.com and B.com have a long and happy relationship together of 10+ years. Web stuff is new to them.
Lawyers.... well, I take your point. I've had to cover myself for screw-ups in the past, so I appreciate the words. We're based in the UK so while litigation is less prevalent than the US, for example, it does still happen. Frankly I'm more worried about the reputations of both organisations, and our members. But yes, I'm writing the documentation in between typing this.
posted by ajp at 7:44 AM on September 5, 2014
A.com and B.com have a long and happy relationship together of 10+ years. Web stuff is new to them.
Lawyers.... well, I take your point. I've had to cover myself for screw-ups in the past, so I appreciate the words. We're based in the UK so while litigation is less prevalent than the US, for example, it does still happen. Frankly I'm more worried about the reputations of both organisations, and our members. But yes, I'm writing the documentation in between typing this.
posted by ajp at 7:44 AM on September 5, 2014
Best answer: Does that sound bonkers?
Not entirely.
You're on the right track, but it's pretty critical that you use authenticated encryption for constructing your encrypted field (and don't call it a hash -- that's a specific thing in cryptography that means something very different from how you're using it. This would be an encrypted token).
What you're describing would be pretty solid as long as you're using something like AES in GCM mode for your symmetric encryption. I've used a similar method (we just pass more data fields in the encrypted token) for authenticating to a vendor with my current employer.
If you don't use authenticated encryption, this is trivially defeatable with an oracle attack.
Also, make sure you use a strong encryption key. Since that would only need to be set up once, make it very long and very random.
posted by bfranklin at 8:01 AM on September 5, 2014
Not entirely.
You're on the right track, but it's pretty critical that you use authenticated encryption for constructing your encrypted field (and don't call it a hash -- that's a specific thing in cryptography that means something very different from how you're using it. This would be an encrypted token).
What you're describing would be pretty solid as long as you're using something like AES in GCM mode for your symmetric encryption. I've used a similar method (we just pass more data fields in the encrypted token) for authenticating to a vendor with my current employer.
If you don't use authenticated encryption, this is trivially defeatable with an oracle attack.
Also, make sure you use a strong encryption key. Since that would only need to be set up once, make it very long and very random.
posted by bfranklin at 8:01 AM on September 5, 2014
Response by poster: @bfranklin Terminology correction noted. And thanks very much for the input.
Hopefully I'll be able to convince the powers-that-be that this is the best solution -- and that there is a problem requiring solution!
posted by ajp at 8:14 AM on September 5, 2014
Hopefully I'll be able to convince the powers-that-be that this is the best solution -- and that there is a problem requiring solution!
posted by ajp at 8:14 AM on September 5, 2014
Does that sound bonkers?
It's not bonkers, but it's complicated in some ways that don't pay off, IMHO.
For one thing, there's no great reason to share a private key in the public/private key sense; at that point you're really just as well off sharing a secret - some cryptographic basis for symmetrically encrypting and decrypting something. Maybe this is what you mean, but just in the sense of being somewhat clear in your terminology I point it out.
It sounds from your description that you're trying to avoid creating these short-life tokens on the destination - you want something to happen on the source side that makes up some thing which the destination validates, without some back-channel communication. That's fine, for what it is, but really you're creating a secret handshake that you want people to be able to see without figuring out how to reproduce.
For that purpose you could use a hash, which as bfranklin points out has a particular meaning. You could hash some mutually agreed-upon daily or hourly changing fact (perhaps Nth day of year and Xth hour of the day in UTC) with a salt of IAMYOURSECRETTHEREAREMANYLIKEITBUTTHISONEISMINE. The source hands that hash over and the destination creates the same hash and compares the two.
This has the advantage that if your programming resources are just sort of middling PHP folks (you mentioned wordpress) they can use the built-in MD5 function to do all of this. It has the disadvantage that you have to do this hashing & comparing of results that doesn't let you encode information you don't already know like the username.
For that you need encrypt & decrypt capability, which a simple public/private key system can be used. PHP also has openssl support, provided both servers have openssl installed. So you let B.com have the public key because it can be shared with the world without fear and they use it to encode the username & that mutually agreed upon secret and hand it over. Then your end decodes it and does the checking.
Probably what you want to do for real security here if there's no back channel communication is for both sides have their own public&private key sets. So B.com has their own private key and A.com's public key. A.com has their own private key and B.com's public key.
B.com, upon serving a page, looks up your shared phrase which y'all can change when you like. At the moment it's "A is my BFF." It adds the current date and time in a format you agree upon. It signs that phrase with B's private key. It combines that signed chunk with the connecting username and encrypts it with A's public key, then creates a button on the page that HTTP POSTs (so you don't have to url encode this stuff into a ?key=ygdkjanslkdnakjnadskj sort of thing) that will post to A.com's destination.
A.com, when someone comes in POSTing that data to a.com/bloginpage, uses its A's private key to decrypt the message. Now it has the username and this signed message. It validates the signature using B's public key and looks at that passed in date and time to make sure this is still valid - it isn't some old-ass thing someone sniffed off the wire a day ago.
Did we discuss that you need to be doing this over https? Really, just make all of A.com https only. For a userbase as small as yours there's not any real CPU repercussion. If you don't have the budget for a cheap cert then I don't know what to tell you.
The above would work because signing things with a private key that can be validated by someone with that person's public key is a thing. Adding the short and simple mutually agreed upon phrase adds a little anti-brute-force that, to be honest, I am not really sure is actually necessary - their simply signing the time with their private key may be enough. Anyone who could penetrate their stuff well enough to lift the key could lift the phrase, and vice versa. The only upside is you can rotate it periodically which you can't exactly do with their key (but really you can).
posted by phearlez at 8:37 AM on September 5, 2014
It's not bonkers, but it's complicated in some ways that don't pay off, IMHO.
For one thing, there's no great reason to share a private key in the public/private key sense; at that point you're really just as well off sharing a secret - some cryptographic basis for symmetrically encrypting and decrypting something. Maybe this is what you mean, but just in the sense of being somewhat clear in your terminology I point it out.
It sounds from your description that you're trying to avoid creating these short-life tokens on the destination - you want something to happen on the source side that makes up some thing which the destination validates, without some back-channel communication. That's fine, for what it is, but really you're creating a secret handshake that you want people to be able to see without figuring out how to reproduce.
For that purpose you could use a hash, which as bfranklin points out has a particular meaning. You could hash some mutually agreed-upon daily or hourly changing fact (perhaps Nth day of year and Xth hour of the day in UTC) with a salt of IAMYOURSECRETTHEREAREMANYLIKEITBUTTHISONEISMINE. The source hands that hash over and the destination creates the same hash and compares the two.
This has the advantage that if your programming resources are just sort of middling PHP folks (you mentioned wordpress) they can use the built-in MD5 function to do all of this. It has the disadvantage that you have to do this hashing & comparing of results that doesn't let you encode information you don't already know like the username.
For that you need encrypt & decrypt capability, which a simple public/private key system can be used. PHP also has openssl support, provided both servers have openssl installed. So you let B.com have the public key because it can be shared with the world without fear and they use it to encode the username & that mutually agreed upon secret and hand it over. Then your end decodes it and does the checking.
Probably what you want to do for real security here if there's no back channel communication is for both sides have their own public&private key sets. So B.com has their own private key and A.com's public key. A.com has their own private key and B.com's public key.
B.com, upon serving a page, looks up your shared phrase which y'all can change when you like. At the moment it's "A is my BFF." It adds the current date and time in a format you agree upon. It signs that phrase with B's private key. It combines that signed chunk with the connecting username and encrypts it with A's public key, then creates a button on the page that HTTP POSTs (so you don't have to url encode this stuff into a ?key=ygdkjanslkdnakjnadskj sort of thing) that will post to A.com's destination.
A.com, when someone comes in POSTing that data to a.com/bloginpage, uses its A's private key to decrypt the message. Now it has the username and this signed message. It validates the signature using B's public key and looks at that passed in date and time to make sure this is still valid - it isn't some old-ass thing someone sniffed off the wire a day ago.
Did we discuss that you need to be doing this over https? Really, just make all of A.com https only. For a userbase as small as yours there's not any real CPU repercussion. If you don't have the budget for a cheap cert then I don't know what to tell you.
The above would work because signing things with a private key that can be validated by someone with that person's public key is a thing. Adding the short and simple mutually agreed upon phrase adds a little anti-brute-force that, to be honest, I am not really sure is actually necessary - their simply signing the time with their private key may be enough. Anyone who could penetrate their stuff well enough to lift the key could lift the phrase, and vice versa. The only upside is you can rotate it periodically which you can't exactly do with their key (but really you can).
posted by phearlez at 8:37 AM on September 5, 2014
I'd avoid electronic solutions entirely here. Snail-mail a letter to each registered user at the address on record with the company saying "Effective 12:01AM on September 15, 2014, the password for the foo system will be 'lolbuttz99'". This letter should not include the username or the URL.
posted by bac at 8:48 AM on September 5, 2014
posted by bac at 8:48 AM on September 5, 2014
I'm going to disagree with phearlez on using public key cryptography. It is incredibly easy, especially for folks with a lack of knowledge of the underpinnings of crypto, to screw things up. Doubly so with a library like openssl.
If you must use public key, use a library like NaCl (pronounced "salt") that makes good decisions on your behalf and uses a limited API to only expose relatively correct crypto implementations to you.
The other issue here is key distribution. Reading a new passphrase for symmetric over the phone is easy. Revoking certificates is a pain in the ass.
On further thought, I'm realizing if you go with the encrypted token solution, the proposed implementation is vulnerable to replay attacks. You would need to include a nonce with your payload in the token that expires once used, so you can't just used the same encrypted token over and over again within the lifetime window.
posted by bfranklin at 8:53 AM on September 5, 2014
If you must use public key, use a library like NaCl (pronounced "salt") that makes good decisions on your behalf and uses a limited API to only expose relatively correct crypto implementations to you.
The other issue here is key distribution. Reading a new passphrase for symmetric over the phone is easy. Revoking certificates is a pain in the ass.
On further thought, I'm realizing if you go with the encrypted token solution, the proposed implementation is vulnerable to replay attacks. You would need to include a nonce with your payload in the token that expires once used, so you can't just used the same encrypted token over and over again within the lifetime window.
posted by bfranklin at 8:53 AM on September 5, 2014
Response by poster: @bac Unfortunately the cost of that would be untenable. Like I said: zero budget.
posted by ajp at 9:13 AM on September 5, 2014
posted by ajp at 9:13 AM on September 5, 2014
It is incredibly easy, especially for folks with a lack of knowledge of the underpinnings of crypto, to screw things up. Doubly so with a library like openssl.
...
On further thought, I'm realizing if you go with the encrypted token solution, the proposed implementation is vulnerable to replay attacks. You would need to include a nonce with your payload in the token that expires once used, so you can't just used the same encrypted token over and over again within the lifetime window.
Yeah, it's sub-optimal for sure. I was mentioning things that seemed likely to be manageable by reasonably naive coders/support staff and offered that up since ajp implied that some back-channel communication wouldn't be doable. I think the simplest solution is that the B server uses the PHP curl-type libraries to ask for a new token (using whatever fairly simple authentication to validate itself) and then that's used in a link for the user. The moment it's used the A server can invalidate it.
Done this way you can have a lone username and password for the B server to authenticate itself to A which you can change as often or infrequently as you like. Your generated tokens can't be reverse-engineered since they're being locally generated by A (rather than via a methodology that can be deduced) and invalidated immediately upon use.
I am not sure how you manage a nonce without this back-channel work unless both sides keep a big "pool" of pre-populated items and invalidate them as they're handed out/used. And that creates the problem of B handing off Nonce3 and it never being used, so it doesn't get deleted from the valid pool at A until you repopulate both pools again. Ugh.
posted by phearlez at 9:33 AM on September 5, 2014
...
On further thought, I'm realizing if you go with the encrypted token solution, the proposed implementation is vulnerable to replay attacks. You would need to include a nonce with your payload in the token that expires once used, so you can't just used the same encrypted token over and over again within the lifetime window.
Yeah, it's sub-optimal for sure. I was mentioning things that seemed likely to be manageable by reasonably naive coders/support staff and offered that up since ajp implied that some back-channel communication wouldn't be doable. I think the simplest solution is that the B server uses the PHP curl-type libraries to ask for a new token (using whatever fairly simple authentication to validate itself) and then that's used in a link for the user. The moment it's used the A server can invalidate it.
Done this way you can have a lone username and password for the B server to authenticate itself to A which you can change as often or infrequently as you like. Your generated tokens can't be reverse-engineered since they're being locally generated by A (rather than via a methodology that can be deduced) and invalidated immediately upon use.
I am not sure how you manage a nonce without this back-channel work unless both sides keep a big "pool" of pre-populated items and invalidate them as they're handed out/used. And that creates the problem of B handing off Nonce3 and it never being used, so it doesn't get deleted from the valid pool at A until you repopulate both pools again. Ugh.
posted by phearlez at 9:33 AM on September 5, 2014
I am not sure how you manage a nonce without this back-channel work unless both sides keep a big "pool" of pre-populated items and invalidate them as they're handed out/used. And that creates the problem of B handing off Nonce3 and it never being used, so it doesn't get deleted from the valid pool at A until you repopulate both pools again. Ugh.
Per-user counter. When it gets used, all values <= that nonce are invalidated. The nonce doesnt need to be strong since it would be wrapped in auth'd encryption.
posted by bfranklin at 9:57 AM on September 5, 2014
Per-user counter. When it gets used, all values <= that nonce are invalidated. The nonce doesnt need to be strong since it would be wrapped in auth'd encryption.
posted by bfranklin at 9:57 AM on September 5, 2014
Can you use something like Centrify to provide an external identity service? From memory, small deployments with them are free (we didn't end up using them - so I can't vouch for capability/ease of deployment).
If what's on the site is subject to the data protection act or is regulated by the FCA then there's a legislative requirement to have appropriate security in place. Going ahead as is may simply not be an option, and a small budget will pale compared to the potential fines - let alone the ruined 10 year business relationship with the client.
This sounds like a situation where the only answer is to say no.
posted by dvrmmr at 11:10 AM on September 5, 2014
If what's on the site is subject to the data protection act or is regulated by the FCA then there's a legislative requirement to have appropriate security in place. Going ahead as is may simply not be an option, and a small budget will pale compared to the potential fines - let alone the ruined 10 year business relationship with the client.
This sounds like a situation where the only answer is to say no.
posted by dvrmmr at 11:10 AM on September 5, 2014
Per-user counter. When it gets used, all values [less than or equal] that nonce are invalidated. The nonce doesnt need to be strong since it would be wrapped in auth'd encryption.
But B doesn't ever know if A consumed the nonce so it keeps increasing by one. A validates phearlez the first time on nonce 10000 (assuming that's the number we mutually 'agree' to start at) but then next week gets one handed over for 10008. Since it doesn't know if B handed out 7 urls that never got used it has to accept it. How wide a window does it accept? What do you do when the window gets too large?
posted by phearlez at 11:13 AM on September 5, 2014
But B doesn't ever know if A consumed the nonce so it keeps increasing by one. A validates phearlez the first time on nonce 10000 (assuming that's the number we mutually 'agree' to start at) but then next week gets one handed over for 10008. Since it doesn't know if B handed out 7 urls that never got used it has to accept it. How wide a window does it accept? What do you do when the window gets too large?
posted by phearlez at 11:13 AM on September 5, 2014
But B doesn't ever know if A consumed the nonce so it keeps increasing by one. A validates phearlez the first time on nonce 10000 (assuming that's the number we mutually 'agree' to start at) but then next week gets one handed over for 10008. Since it doesn't know if B handed out 7 urls that never got used it has to accept it. How wide a window does it accept? What do you do when the window gets too large?
It accepts anything that's numerically greater than the previously used. Use a 32 bit number and you're good for ages. 64 bit if you're a large site
Keep the threat model for this specific implementation in mind. If bad tokens are being generated by B, then either a user's account on B is compromised (and nothing you can do because B is the source of truth), or B's entire site is compromised, in which case the secret key is compromised, and what A accepts doesn't matter, because again, B is the source of truth.
posted by bfranklin at 11:36 AM on September 5, 2014
It accepts anything that's numerically greater than the previously used. Use a 32 bit number and you're good for ages. 64 bit if you're a large site
Keep the threat model for this specific implementation in mind. If bad tokens are being generated by B, then either a user's account on B is compromised (and nothing you can do because B is the source of truth), or B's entire site is compromised, in which case the secret key is compromised, and what A accepts doesn't matter, because again, B is the source of truth.
posted by bfranklin at 11:36 AM on September 5, 2014
The existing plan is for us to regularly change the password, and publish it in the password-protected members' areas of B.com. Yep -- publish the password online in plain-text.
I'm probably missing something here, but why wouldn't you just serve this page over SSL? (Because the login page for b.com uses SSL, riiight? If not, that's a whole 'nother problem.) I.e., it's not the initial transmission that's the problem. Nor is the "same username/password" for everyone requirement the problem, because it only takes one user to compromise the site, whether the login info they leak is unique or shared. (Though unique passwords can be useful for fingering the culprit.) The real security issue in this situation is the 5000 non-techy people who are going to email that login info to each other.
posted by bricoleur at 12:38 PM on September 5, 2014
I'm probably missing something here, but why wouldn't you just serve this page over SSL? (Because the login page for b.com uses SSL, riiight? If not, that's a whole 'nother problem.) I.e., it's not the initial transmission that's the problem. Nor is the "same username/password" for everyone requirement the problem, because it only takes one user to compromise the site, whether the login info they leak is unique or shared. (Though unique passwords can be useful for fingering the culprit.) The real security issue in this situation is the 5000 non-techy people who are going to email that login info to each other.
posted by bricoleur at 12:38 PM on September 5, 2014
This thread is closed to new comments.
posted by The Michael The at 4:46 AM on September 5, 2014