@bagder We need more context 😅

@colin_mcmillen @bagder wait, you can dump the config without authentication of any kind, which includes the devices password hashes, and somehow you can just pass those hashes back to authenticate to the device?
No, that all tracks with the sophistication of this “fix”.

15 April at 10:27 | Open on hachyderm.io

0xC0DEC0DE07E8

@colin_mcmillen @bagder
✅ don’t store passwords in plaintext
❓ don’t transmit credentials in the clear
❌ prevent replay attacks

15 April at 11:13 | Open on hachyderm.io

Jess👾

I've got some really bad news for you about just how many devices there are out there that fail at LEAST 1 of those, and a nontrivial number that fail all 3.

@c0dec0dec0de
@colin_mcmillen @bagder

15 April at 13:16 | Open on infosec.exchange

Todd Knarr

@JessTheUnstill @c0dec0dec0de @colin_mcmillen @bagder TBF using symmetric encryption/hashing it's hard to avoid either storing or transmitting the credentials in the clear. To avoid both you need to use asymmetric (public-key) encryption and only transmit nonces (what hardware tokens do with certificate-based authentication).

15 April at 14:25 | Open on mstdn.social

Jess👾

That's not how that works.

When we talk about exchanging credentials in the clear, we're talking stuff like telnet where a MitM can just dump your password via Wireshark. An ssh connection sets up a secure tunnel between the systems, and then compares cryptographic hashes. The plain text password never is stored on disk anywhere, just the one way salted hash of the password.

https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

@tknarr
@c0dec0dec0de @colin_mcmillen @bagder

That's not how that works.

When we talk about exchanging credentials in the clear, we're talking stuff like telnet where a MitM can just dump your password via Wireshark. An ssh connection sets up a secure tunnel between the systems, and then compares cryptographic hashes. The plain text password never is stored on disk anywhere, just the one way salted hash of the password.

Expand text...

15 April at 14:33 | Open on infosec.exchange

0xC0DEC0DE07E8

@JessTheUnstill
Yup. This device is probably transmitting stuff in the clear because it’s got a web server running without encryption. The “normal” answer would be to enable TLS on your web server, but how do you do that when you’re embedded and cant just bake in CA-signed TLS certs?
The thing that interests me about this failure is that you can pass-the-hash to get in.

@tknarr @colin_mcmillen @bagder

@JessTheUnstill
Yup. This device is probably transmitting stuff in the clear because it’s got a web server running without encryption. The “normal” answer would be to enable TLS on your web server, but how do you do that when you’re embedded and cant just bake in CA-signed TLS certs?
The thing that interests me about this failure is that you can pass-the-hash to get in.

Expand text...

15 April at 14:47 | Open on hachyderm.io

Colin McMillen

@c0dec0dec0de @JessTheUnstill @tknarr @bagder my printer self-signs a cert. That's better than clear text even if there's the browser warning.

15 April at 16:02 | Open on piaille.fr

0xC0DEC0DE07E8 replied to Colin

@colin_mcmillen
Yeah, I’m thinking that’s probably true. You don’t have proof you’re talking to the right device (and therefore vulnerable to MITM attacks notionally but you connected to this thing via an IP address that you got out-of-band so unlikely), but you’re getting the other security benefits (including encrypting your password in transit and resistance to replay attacks).
@JessTheUnstill @tknarr @bagder

15 April at 16:20 | Open on hachyderm.io