Why No One Legit Will Give You a Password by Phone or Chat

TL;DR — Legitimate teams do not send passwords over the phone or in chat because a password is a reusable secret: once copied, overheard, forwarded, or logged, it can be used again by anyone who has it. The right fix is almost always: reset the password yourself through the service’s sign-in flow, or have the admin create your own account, temporary link, or one-time access method instead of sharing a secret. Reading time: ~7 min

What it is and where it sits

This topic is really about identity and access: how a system proves who you are and decides what you can do.

A password is a shared secret (something both you and the system know). That is the problem. If someone tells you the password in a phone call, voicemail, SMS, Slack message, Teams chat, WhatsApp message, or support ticket, that secret is no longer controlled. It may be:

• overheard
• screenshot
• copied into logs
• synced to another device
• stored in a chat history forever
• reused later by the wrong person

Modern systems try to avoid shared secrets moving between humans. Instead, they prefer one of these patterns:

• Self-service password reset via email or SMS
• Magic link (a sign-in link that works once or for a short time)
• Single sign-on (SSO) (sign in with your company account, like Google Workspace or Microsoft Entra ID)
• Your own named account with the right permissions
• Multi-factor authentication (MFA) (a second proof, like an app code or security key)
• Temporary access that expires automatically

In a typical setup, support staff do not know your current password at all. Good systems store only a password hash (a one-way scrambled form used for checking, not recovering, the original password). That means they can verify a password you enter, but they cannot read it back and tell it to you.

Here is the architecture context:

You
  |
  | 1. Enter email / click "Forgot password?"
  v
App or Website
  |
  | 2. Sends reset request
  v
Identity system / auth service
  |
  | 3. Creates one-time token
  v
Email or SMS provider
  |
  | 4. Delivers reset link/code
  v
You
  |
  | 5. Set a new password or use one-time sign-in
  v
App or Website

What this replaces is the old habit of saying, “Here’s the password, please log in.” That old model is weak because many people end up using the same credential, nobody has a clean audit trail, and changing access later becomes painful.

How it actually works

Let’s walk one realistic example end to end.

Example: you need access to the client portal, but support will not send the password

You call your software agency and say, “Can you just message me the password?” They refuse. That is not them being difficult; it is the secure design working as intended.

Step by step:

1. You go to the sign-in page and click Forgot password? or Reset password.
2. You enter your email address.
3. The app sends that request to its identity system.
4. The identity system creates a one-time token (a random string used once, usually expiring in 15-60 minutes).
5. The system stores only the token’s safe representation and an expiry time.
6. The system emails you a link like https://portal.example.com/reset?token=....
7. You click the link, choose a new password, and sign in.
8. The old password, if there was one, is no longer needed.
9. The system logs that your account changed its password at a specific time.

Why is this better than support sending a password in chat?

• The support agent never learns your new password.
• The reset link expires.
• The action is tied to your email inbox or approved recovery method.
• The event is auditable.
• If your access should later be removed, the admin disables your account, not a shared password used by five people.

What if support really does need to help right now?

A good team uses one of these alternatives:

• Invite your email as a new user in the admin dashboard
• Trigger a password reset from the admin side, which sends the reset to you directly
• Create a temporary account that expires
• Use screen sharing while you type your own password, without saying it aloud
• Use SSO so there is no app-specific password to share at all

In other words: they can help you get access, but they should not transmit a reusable secret person-to-person.

When to use it (and when not to)

The practical question is not “Should someone give me the password?” It is “What access method should I ask for instead?”

You probably don’t need password sharing if...

• the service has a Reset password link
• the admin can add users from a dashboard
• your organization has an identity provider (company sign-in)
• the task can be done with delegated access or a lower-permission role

The rare exception

There are still old systems in the world with a single shared account and no user management. If you are stuck with one, treat that as technical debt to remove, not as a normal operating model. If you must use it briefly, rotate the password immediately after use and move to named accounts as soon as possible.

Trade-offs

Secure access methods are better, but they are not free.

A blunt but useful rule: convenience usually favors shared passwords in the short term; security, accountability, and maintainability favor named access in the long term. Most agencies that have been burned by access incidents stop sharing passwords because the cleanup cost is much higher than the sign-in friction.

In practice

Below are concrete examples of what “do the secure thing instead” looks like.

Example 1: Nginx basic auth for a staging site

This is not ideal for long-term user management, but it shows an important point: even with simple password protection, you still do not send the password in chat if you can avoid it. You create or rotate credentials, then deliver access through a safer channel or have the user set their own credentials if the tool supports it.

⚠️ Rotating credentials on a shared environment will immediately lock out anyone still using the old password. Do this during a planned window if multiple people depend on the site.

sudo apt-get update
sudo apt-get install -y apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd alice
sudo nginx -t && sudo systemctl reload nginx

This installs the htpasswd tool, creates a password file, adds user alice, and reloads nginx. The gotcha: -c creates a new file; if you run it again by mistake, you can overwrite the existing user list.

server {
    listen 443 ssl;
    server_name staging.example.com;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

This protects a site with HTTP Basic Auth (browser username/password prompt). The gotcha: Basic Auth is only acceptable over HTTPS; without TLS (encrypted web traffic), the credential can be intercepted.

Example 2: A password reset email flow in an application

If you run software for customers, this is the pattern you want: generate a one-time token and send a reset link, rather than exposing or transmitting any existing password.

{
  "event": "password_reset_requested",
  "user_email": "alex@example.com",
  "token_ttl_minutes": 30,
  "delivery": "email",
  "reset_url": "https://portal.example.com/reset-password?token=<one-time-token>"
}

This is a simplified example of the data involved in a reset request. The gotcha: never log the full live token in application logs; logs are often visible to staff and retained for a long time.

Subject: Reset your password

We received a request to reset your password.

Use this link within 30 minutes:
https://portal.example.com/reset-password?token=<one-time-token>

If you did not request this, you can ignore this email.

This is the kind of email a system should send automatically. The gotcha: the link should expire quickly and become invalid immediately after use.

Dashboard-first actions to ask for

If you are the customer and need access, these are the exact actions to request from the admin or agency:

• “Please add me as a user under your provider’s dashboard, usually something like Settings → Users, Team, or Members.”
• “Please trigger a password reset from the account admin screen if that option exists.”
• “Please send me an invite link that expires.”
• “If this app supports company sign-in, please enable SSO for our domain.”

If the team replies, “We’ll just send the password here,” that is your cue to push back.

What to say instead

You can copy and paste this:

For security, please don’t send a password in chat or over the phone. Please either:
1) send me a password reset link,
2) create my own user account, or
3) send a time-limited invite.
If SSO is available, I’d prefer that.

This works because it does not just reject the unsafe option; it gives three concrete alternatives.

Further reading

• OWASP Authentication Cheat Sheet
• NIST SP 800-63B Digital Identity Guidelines: Authentication and Lifecycle Management
• The "HTTP Authentication" article in the MDN Web Docs
• The "Passwords" and "Multi-factor authentication" guidance in the UK NCSC website
• Web Authentication: An API for accessing Public Key Credentials Level 3 (WebAuthn spec)

This article was written by an AI system and published pending human review. Verify anything you intend to act on.