39

In my work as a developer, I need username/password combo's from the customer sometimes to make sure the settings on 3rd party services are correct to work with the website/application we are building. E.g. a payment provider that we use on a game website.

What would be the good way to ask for their username and password so that it stays secure? If I send them an email, for sure, they are just going to send me back a plain text email with the password, but that is not secure.

UPDATE:

I see my question got a bit misunderstood, so I will add an example:

Suppose I am a developer for CoolSoft, a software company. Another company (let us call them Games, Inc.) wants us to create a website for them. This website will use 3rd party services for payment and customer support which we need to integrate with. Games, Inc. creates accounts with the payment provider and the customer support provider. But they are totally not technical and we need to have their credentials to set the correct callback URLs, etc.. How can they safely send their password to us so we can fix the settings on their accounts (We never meet in person)?

Community
  • 1
Wim Deblauwe
  • 549
  • 1
  • 4
  • 7
  • 6
    Is human contact out of the equation? – MadWard Jun 23 '16 at 11:49
  • Yes, forgot to mention that indeed. – Wim Deblauwe Jun 23 '16 at 11:50
  • While the answer from Philip seems good, that isn't always a possible solution, so you could use a end-to-end encrypted app like oleksii mentioned. – DarkSecurity Jun 23 '16 at 12:11
  • 1
    Just noticed a similar question: http://superuser.com/questions/21391/how-can-clients-easily-and-securely-send-me-passwords – Wim Deblauwe Jun 23 '16 at 15:25
  • 13
    once you know the customer's creds, what stops them from blaming you for any problem that arises at any point in the future? You really don't want that information – Neil Smithline Jun 23 '16 at 18:42
  • 16
    I work with a third party site like this where you absolutely do need these credentials to do development. What we do (since this is always initial development type work for us) is use a throw away password during development. Then as part of the product handoff we walk the customer through taking over the credentials and setting their own real password. This eliminates the problems everyone is mentioning about being blamed for future actions. – Ukko Jun 23 '16 at 19:17
  • 6
    @NeilSmithline Uh, the fact that they changed their password as soon as OP finished doing what he's doing, because they follow sensible security policy like sane people? – Superbest Jun 23 '16 at 19:41
  • Please check your website for SQL injection. Your code smells. – noɥʇʎԀʎzɐɹƆ Jun 25 '16 at 20:04
  • You should be able to simply add an admin hook in your code. Like a hidden parameter `?adminlogin=true` and then enter the admin password in the user's account. The SQL could check for the admin's password instead. – noɥʇʎԀʎzɐɹƆ Jun 25 '16 at 20:06
  • I am sorry, your example makes things unclear to me. Can you precise the end? Why would you need to have the credentials? Why would you have "to fix the settings on their accounts"? – Nicolas Barbulesco Jun 26 '16 at 17:38
  • Your example is too abstract. What does the company Games do? And what is the site CoolSoft does? – Nicolas Barbulesco Jun 26 '16 at 17:42
  • "We never meet in person" Maybe you should. It seems to me that there are too many actors in this play. CoolSoft, Games, the payment provider, the customer support provider: already 4 actors, this is too many. I think that this is part of your problem. – Nicolas Barbulesco Jun 26 '16 at 17:53
  • Could I have a response to my `?adminlogin=true` suggestion? – noɥʇʎԀʎzɐɹƆ Jun 26 '16 at 20:14
  • 4
    I'm baffled by the number of people expressing surprise at this scenario. Yes, in an ideal world, every actor would be a subscriber to this site, and collaborate on the solution. But the question seems perfectly reasonable to me as "given an unfortunate situation which I am not fully in control of, how do I minimise the security risks". – IMSoP Jun 27 '16 at 08:31
  • For a concrete example, consider a DNS control panel. These are completely baffling to non-technical users, but may need to be accessed multiple times as part of a deployment. In an ideal world, the DNS provider would allow temporarily delegating access to a second username, but in the real world, you're going to need to login to that control panel somehow. – IMSoP Jun 27 '16 at 08:35

9 Answers9

144

You don't.

When you teach users to give their username and password to someone, you train them to be vulnerable to phishing or other social engineering attacks.

Instead, design the system in a way that an administrator can view and edit these settings without requiring the users credentials.

When you are in a situation where you really need to see things from the perspective of the user to troubleshoot a problem, ask the user to type in the password for you and then let them show you the problem. This can be done either in person or with a remote administration tool.

When you are in a situation where the customer has credentials you need in your application to integrate with a 3rd party solution, develop your application in a way that a non-technical user has an easy to use user interface to set these credentials. You will need that anyway in case the customer needs to change them and you are unavailable.

The user won't have to enter this until the application is deployed on their own servers. During development you should use a test account on your end to interface with the 3rd parties. You definitely don't want to cause any costs to your customer because you ran some tests on the 3rd party payment interfaces which didn't work out the way you expected.

Philipp
  • 48,867
  • 8
  • 127
  • 157
  • 34
    ... when possible. Even in modern environments, there always seems to be system accounts, vendor admin accounts, or other credentials that end up being shared. – schroeder Jun 23 '16 at 12:16
  • 3
    I think my question was not clear. I added an example which hopefully makes it clearer. – Wim Deblauwe Jun 23 '16 at 14:41
  • 19
    @WimDeblauwe your question was clear, the correct answer is still "You don't". If you want to test it on your end its better to backup the hash of there credentials ... edit there password/api key ... test ... then restore there credentials. – CaffeineAddiction Jun 23 '16 at 14:50
  • 12
    @schroeder just because it happens all the time doesn't mean it is secure, or a best practice. – CaffeineAddiction Jun 23 '16 at 14:51
  • 3
    It seems to me, the remote administration tool would be the way to go, and would avoid the need to share a password. – Ben Jun 23 '16 at 14:51
  • 7
    @CaffeineAddiction I'm, saying it's not always *possible* ... – schroeder Jun 23 '16 at 14:56
  • 3
    @ben Remote admin does not fit the example in the question – schroeder Jun 23 '16 at 14:59
  • 4
    @WimDeblauwe I updated the answer. My conclusion does not change: You don't need the users passwords and you don't want them. – Philipp Jun 23 '16 at 15:06
  • 1
    @schroeder sure it does, unless I misunderstand what "remote admin" means. I'm picturing a remote desktop session like our IT department does for users on the corporate network when they need help configuring something. The user logs into whatever needs accessing, and support will either guide the user through the configuration or just take control and do it for them. Then over the phone, support can guide the user through disabling or uninstalling whatever remote software was used, if needed. – Ben Jun 23 '16 at 15:39
  • 1
    @ben read Philipp's update to his answer re: 3rd party integration – schroeder Jun 23 '16 at 15:43
  • 1
    As I read the question, it is about _becoming the administrator_, for a company that does not have any suitable own employee, as a contractor. If the system has company account and separate user accounts that can be given permission to the company account, that's fine. But some systems just have company accounts with credentials and then there is no way around passing those credentials. – Jan Hudec Jun 24 '16 at 13:53
  • @JanHudec: I would read your objection as "there is no way without incurring unreasonable expense". There is always a way. But needing both parties to install remote software, or training staff, or adding a(n originally unplanned) credentials management component to a system may affect budget and/or time. In those cases, a security-conscious organisation should at least be aware of better practice and be able to explain to themselves and to the customer what compromises they are making, and how to minimise risk. – Neil Slater Jun 26 '16 at 07:57
  • 2
    @NeilSlater, there is a _third party_ here. Think Google Play — they allow giving permissions to other accounts now, but early on they didn't. So the contractor hired to handle it needs access and if there is only one set of credentials, well, the contractor needs them. The “unreasonable expense” is “forgetting about the business altogether” here. Also there is no principal difference between a contractor and an employee — somebody needs to be trusted by the company to have the master password. – Jan Hudec Jun 27 '16 at 05:03
  • 1
    This is very telling about our the security industry that the top voted answer isn't a solution and in fact doesn't take many cases into consideration. The OP isn't asking for best practices, he's asking for a way to securely transfer passwords. – Ijustpressbuttons Jun 27 '16 at 15:39
20

There are numerous "team password managers" that allow teams to share, change, and revoke access to credentials. Most are paid (or free for small teams), but this is likely the best way to go. They typically provide encryption, as well as access control over the access to specific credentials.

schroeder
  • 123,438
  • 55
  • 284
  • 319
13

The only viable option I see (which hasn't been mentioned yet, odd) is to have the client setup account(s) with the appropriate permissions for you to use on these systems/internet services. This way, they handle the vendor relations and payment, but you have accounts that have the access you require.

As Phillip's answer stated, you simply don't ask for or participate in the sharing of passwords. It's just bad all around, as you're putting yourself in a position to be blamed if something goes wrong when someone else uses the shared account. ("I know my employees would never do something like that, and you're the only people we shared the password with, so it must be something one of you did!!")

Community
  • 1
HopelessN00b
  • 3,385
  • 19
  • 27
  • perfect answer, I'd also add the concern of SLAs to be modified if passwords were to be exchanged, I would never let anyone have any password without a legal binding. And the advantage of loss of the credentials for your job related less privileged account would not be as harmful as losing the original creds (god forbid if it happens ever). – GhostSpeaks101 Jun 24 '16 at 15:10
  • Conceptually this is a good idea but it still pushes requirements on the client which may be hard to fulfill. It still requires some technical know-how on the client-side. – Ijustpressbuttons Jun 24 '16 at 22:50
  • @Ijustpressbuttons setting up user accounts is generally not a technical process. A client who finds this to be an onerous requirement is going to be a nightmare. – HopelessN00b Jun 25 '16 at 16:24
  • @HopelessN00b That depends on the system they're setting up accounts in, surely? Some systems will simply not have the abilty to create additional logins or delegate access; others will have complex systems of permissions that need navigating. Like so many of the answers here, this seems to depend on the ability to influence the third party's security protocols in order to dodge the question. At best, it could go on a list of "exhaust these possibilities before you proceed". – IMSoP Jun 27 '16 at 13:51
  • @IMSoP There is a lot of utter crap out there, sure, a "cloud"/web/whatever service (3rd party service that integrates with a website) that is difficult to setup new users/accounts on is a special kind of crap. It's like smoking and pumping gas at the same time. Yeah, you can usually find a way to make it work, but you *really* shouldn't be doing it. If your vendors are that bad, run. – HopelessN00b Jun 27 '16 at 14:29
  • 2
    @HopelessN00b I strongly disagree. The default permission model for most systems is that you sign up for an account, and that account "owns" everything within it. The ability to create sub-accounts, or delegate access to your configuration to some other account, is pretty rare. If you refused every contract where someone had picked a less-than-perfect vendor, you'd be driving yourself out of a job. – IMSoP Jun 27 '16 at 14:52
12

I summarize the situation as following

  • you need access to a third party service with account of your client
  • meeting in person is not easily achieved
  • a solution involving the client installing software or following a complex procedure is undesirable

I think the best solution would be: Send a new password TO THEM

You send them a password in a secure fashion and give them instructions (via phone?) to please set the password on their accounts temporary to your proposed password. - Then you can use it to log into the page. And when you are done, they can reset their password to the original value.

An easy way would be a one-time link in the mail, which leads to a page displaying the password. The client can click it, copy the password. And an attacker will not be able to access the same password-link. (Of couse a targeted MitM attack with changing the mail contents would still be possible and could be mitigated by signing the mail)

You could also tell them the temporary password via phone, they write it down and change their account password temporarily to the one you tell them.

This backwards way has several benefits:

  • Your client can honour the rule "Never share your password"
  • You can choose a secure way of relaying the password, you don't have to teach your client a secure way.
  • Your client stays in control of giving and revoking your access
Falco
  • 1,493
  • 10
  • 14
6

There are literally tons of solutions for transmitting data (e.g., credentials) securely.

  • If the client supports PGP / GPG encryption, you can exchange Public Keys and encrypt the emails
  • There is also companies that specialize in SecureMail (ZixCorp) or you can purchase your own (Cisco Ironport).
  • If you have a collaboration site (e.g., customer portal for the client) they can upload the credentials to the portal. FYI Alfresco is a freeware application that does a good job of this.
  • Even though human contact is out of the question, are you able to text? Perhaps they can send a text message of the password and provide the username via another channel.
  • If all else fails, smoke signals and snail mail are still a thing, but the above methods are the most common vectors.
HashHazard
  • 5,105
  • 1
  • 17
  • 29
  • 1
    Text isn't secure unless you do it through an app such as Signal – rhymsy Jun 23 '16 at 17:42
  • @rhymsy exactly why I said only send the password. A text with jumbled characters (and usually via MMS picture instead of actual characters) with no surrounding context doesn't do the interceptor any good. – HashHazard Jun 23 '16 at 22:56
  • @rhymsy - This is unclear. Can we send SMS through the app Signal? – Nicolas Barbulesco Jun 26 '16 at 18:22
  • 1
    @Hollowproc - If the interceptor wants to intercept the password, then a text of meaningless characters is perfectly meaningful for the interceptor. For passwords, I prefer the rule **“Never write it”**, and I recommend rather the telephone. We can even be paranoid and split the communication into several phone calls. From/to different telephones, from/to different people… – Nicolas Barbulesco Jun 26 '16 at 18:33
  • @NicolasBarbulesco as OP said, telephone is not an option in this scenario. The "Signal" solution also implies that you are trusting a third party with the content of the SMS/MMS message they are "encrypting"; a simple text message with no context should suffice, as intercepting them is harder than you may think and requires additional pieces and an already existing level of compromise that would probably make getting this password trivial by other means. Admittedly, nothing is perfect but it's a calculated risk. In this case, the risk is present, but low, IMHO. – HashHazard Jun 26 '16 at 20:10
  • @Hollowproc - Why would not telephone be an option? This would be strange. – Nicolas Barbulesco Jun 26 '16 at 20:18
  • @NicolasBarbulesco Beats the FOM, but that's what the OP said in the comments under the Question: Is human contact out of the equation? – MadWard Jun 23 at 11:49 Yes, forgot to mention that indeed. – Wim Deblauwe Jun 23 at 11:50 – HashHazard Jun 26 '16 at 20:34
  • @Hollowproc - What is the FOM? – Nicolas Barbulesco Jun 26 '16 at 21:10
  • F*** outta me.. LOL – HashHazard Jun 26 '16 at 21:11
  • 1
    @Hollowproc - I understood that "human contact" as human meeting. Phone is very common in company business. If the telephone really cannot be used, then this is a problem that should be solved, or avoided by fleeing that nightmare project. – Nicolas Barbulesco Jun 26 '16 at 21:19
  • @NicolasBarbulesco, I have my own opinions on the surrounding details of the question as well (so +1), but I tried to stay neutral and pointed to the question asked. – HashHazard Jun 26 '16 at 21:25
6

Keep it simple, but just use two forms of communication. For example, in an email requesting credentials, ask them to reply with username only and then text a temporary password to your number. As soon as possible after you get the credentials, change the temporary password to something else.

Yes, in theory, someone could see the email and hack SS7 to get the password, but if they can do that before you could change from the temp password, you are pwned anyway.

Bill
  • 61
  • 1
  • I don't understand your last paragraph. Maybe you should rewrite it. What is SS7? – Nicolas Barbulesco Jun 26 '16 at 18:05
  • @NicolasBarbulesco: google first hit = https://en.wikipedia.org/wiki/Signalling_System_No._7 is a not very secure protocol used in telephone systems, including cell/mobile systems which handle text messages. Hence, hack SS7 (systems) to get the text (containing the password). – dave_thompson_085 Jun 26 '16 at 21:20
0

You shouldn't be hard-coding callbacks th respond to specific username/passwords. If you are dealing with 3rd party tools you should be setting up those accounts for them and interacting with those tools via API tokens. Much better that you create the account and at the end assign any account credentials over to the customer.

sidewaiise
  • 101
  • 1
  • 1
    The OP is not aiming to store the username and password anywhere; they are aiming to log in personally in order to configure technical details in some third party control panel as part of an application deployment. And setting up new accounts is not always an option, as these may be existing paid-for accounts which need new functionality attaching. – IMSoP Jun 27 '16 at 13:56
0

Doesn't matter the reason, passwords can be changed. In the IT world this comes up a lot, a great example is migration of emails from one server to another, you must have the password to the email inbox being used, no way around it. Best practice is if the service allows, get invited as a user with the permissions you need, but if you need the owner account access for any reason then have them set a different password to the account while you use it, then once your done have them change the password back or set a new one. This ensures that they don't give you a password that they have used over and over for many other accounts and that once your done they have no excuse to say your still using said account.

Andrew.Beardman
  • 1
-1

Strange that noone mentioned OAuth, which, at first glance, is the perfect solution for the problem, as rephrased after the update.

bortzmeyer
  • 217
  • 1
  • 3
  • 3
    OAuth is a solution that would need to be depolyed by the third-party system supplier; the OP is not looking for access to a system they designed themselves. – IMSoP Jun 27 '16 at 08:27