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)?

Improve this question
15
  • 6
    Is human contact out of the equation?
    – Azami
    Commented Jun 23, 2016 at 11:49
  • 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
    Commented Jun 23, 2016 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
    Commented Jun 23, 2016 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
    Commented Jun 23, 2016 at 19:41
  • 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
    Commented Jun 27, 2016 at 8:31

9 Answers 9

Reset to default
143

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.

Improve this answer
14
  • 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 ♦
    Commented Jun 23, 2016 at 12:16
  • 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
    Commented Jun 23, 2016 at 14:50
  • 12
    @schroeder just because it happens all the time doesn't mean it is secure, or a best practice.
    – CaffeineAddiction
    Commented Jun 23, 2016 at 14:51
  • 7
    @CaffeineAddiction I'm, saying it's not always possible ...
    – schroeder ♦
    Commented Jun 23, 2016 at 14:56
  • 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
    Commented Jun 23, 2016 at 15:06
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.

Improve this answer
5
  • 2
    Any examples you can give?
    – Wim Deblauwe
    Commented Jun 23, 2016 at 12:04
  • 1
    @WimDeblauwe if you google "team password manager" you have a lot to choose from
    – schroeder ♦
    Commented Jun 23, 2016 at 12:14
  • 10
    LastPass Enterprise is an example. lastpass.com/enterprise_overview.php
    – Ted
    Commented Jun 23, 2016 at 13:45
  • 2
    And 1Password also has a cloud-based team thingy. 1password.com/teams
    – ziggurism
    Commented Jun 23, 2016 at 16:59
  • 2
    CyberArk PIM works well for larger organizations.
    – esqew
    Commented Jun 25, 2016 at 1:17
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!!")

Improve this answer
6
  • 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
    Commented Jun 24, 2016 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
    Commented Jun 24, 2016 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
    Commented Jun 25, 2016 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
    Commented Jun 27, 2016 at 13:51
  • 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
    Commented Jun 27, 2016 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
Improve this answer
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.
Improve this answer
11
  • 1
    Text isn't secure unless you do it through an app such as Signal
    – rhymsy
    Commented Jun 23, 2016 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
    Commented Jun 23, 2016 at 22:56
  • @rhymsy - This is unclear. Can we send SMS through the app Signal?
    – TheMaskedCucumber
    Commented Jun 26, 2016 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…
    – TheMaskedCucumber
    Commented Jun 26, 2016 at 18:33
  • 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.
    – TheMaskedCucumber
    Commented Jun 26, 2016 at 21:19
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.

Improve this answer
2
  • I don't understand your last paragraph. Maybe you should rewrite it. What is SS7?
    – TheMaskedCucumber
    Commented Jun 26, 2016 at 18:05
  • @NicolasBarbulesco: google first hit = 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
    Commented Jun 26, 2016 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.

Improve this answer
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
    Commented Jun 27, 2016 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.

Improve this answer
-1

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

Improve this answer
1
  • 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
    Commented Jun 27, 2016 at 8:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .