I just entered my keychain password instead of VPN account one. If this action potentially sent my password to the VPN logs, then they now know my IP address and credentials and able to connect me with SSH. I'm worried about connecting, and I don't want to change my credentials because of that.
How many people have done the same and do not have their firewall configured properly.
2025-03-29 · 1 year ago
13 Comments ↓
🚀 stack · 2025-03-29 at 01:40:
There was a time I was furiously typing in my password for something and wondering why it wasn't working, then realized I was typing it into an IRC chat.
🐦 wasolili [...] · 2025-03-29 at 02:22:
This is why im grateful that all major Gemini browsers filter out your password automatically if you try to send it. Here's mine, see: *****************************
try it out yourself!
(jokes)
👻 ps [OP] · 2025-03-29 at 02:26:
@stack, when the mind is busy, anything is possible.
Just interesting how many of these events we haven't even caught..
🐐 drh3xx · 2025-03-29 at 10:27:
Password shouldn't be transmitted in plaintext anyway. Should be a hash of some sort that's checked against a hash of the password for their service that they hold. It doesn't eliminate threat entirely as some hashes but it would require deliberate effort to crack and then they'd have to identity what that password was for (and a username/token to go with it)
🚀 stack · 2025-03-29 at 13:36:
Let me try it with my password: PASSWORD
🚀 lanterm · 2025-03-30 at 12:32:
@drh3xx I know hashing is important for storage, but does hashing a password before transmitting it to the server really provide additional security? I imagine a username+pw hash pair would be just as "useful" to an attacker as a username+pw pair - the service accepts the hash as input, so it would be functionally equivalent to a password.
🚀 stack · 2025-03-30 at 12:51:
It makes it harder to remember, and harder to type in by hand.
🐦 wasolili [...] · 2025-03-30 at 23:25:
does hashing a password before transmitting it to the server really provide additional security? I imagine a username+pw hash pair would be just as "useful" to an attacker as a username+pw pair - the service accepts the hash as input, so it would be functionally equivalent to a password.
it provides some additional security. an attacker can gain access to the victims account, but they're at least unable to learn the user's plaintext password and therefore unable to attempt to gain access to the victim's accounts on other services. And likewise, neither are malicious service operators. ideally nobody would be reusing passwords, buy we know that's not how the world works.
It would also mitigate OP's concern, where they typed in the password for something else into the wrong service. If the hash was sent instead of the plaintext password, they'd have nothing to worry about.
🚀 lanterm · 2025-03-31 at 13:03:
Yeah I get an attacker with a username+pw pair for one site is able to test those across many other sites (i.e. credential stuffing), but I've always had the belief that the source of those datasets were from cracked passwords in breached databases, so credentials in storage, rather than from an attacker monitoring traffic on a system in real time. If you have any published examples of that, I'd love to read more.
Not saying it's not possible, but with security it's kind of an arms race and you need to focus on implementing safeguards that optimize for maximum security + minimum effort. In this scenario, if an attacker already has access to the production machine and is able to snoop on incoming logins over the network, or add extra logging to log credentials in clear text as they come in, what the client does won't really have an effect on the outcome. The attacker owns the system and knows how the client hashes the passwords. It's an extra step of effort where the scenario in which it's designed to overcome makes the effort moot. The danger as a user is whether the server you contact is compromised or not and I don't believe hashing passwords on the client before transmission adds protection there.
So, only looking at credential transmission here and not storage, it seems to me the most reasonable effort a site operator can do is to 1) only accept login credentials over an encrypted connection and 2) never log them or store them beyond that network request. At the same time, the best a user can do to prevent attackers from accessing their other accounts in the case of a breach is to avoid password reuse between sites.
🚀 stack · 2025-09-27 at 18:07:
a while back I was trying to log in somewhere, but it wasn't working for some reason. I kept pounding in my password, then realized it was going straight to an open IRC window...
By then there were many giggles there.
🕷 baran · 2025-09-28 at 00:53:
me too)
🦂 zzo38 · 2025-09-28 at 02:48:
Using hashes won't help much, but using public/private key for authentication would help (which is what happens when you use a X.509 certificate). Only accepting credentials over an encrypted connection also does not help as much, in case the server is compromised or if you connect to the wrong server and do not check that it is the right one.
📻 eugene · 2025-09-28 at 07:15:
In practice, logging entered passwords in plaintext is very rare: it exposes the service to legal liabilities and usually serves no practical purpose since when they want to log in as you on their service, they can do it anyway. (On many kinds of services, this is an essential tech support feature.)
That said... what are you doing typing passwords in manually and from memory? Get a password manager.