/Users/AuthenticateByName requires plaintext password?!

[Guest]

G'day!

Since I was frustrated lately with Plex's lack of a public API I started looking at Emby more closely - and I was positively surprised. An API! With documentation! Wee!

Looking through the authentication process I tried the token approach first which is totally fine for development. If I want to treat actual end users to my (planned) app though I need something more user friendly. Enter: /Users/AuthenticateByName. However I was somewhat aghast reading the documentation. This request requires sending the plain text password over the network?

In all computer security courses and articles I consumed so far that would be considered very bad practice. The plaintext password should *never* leave the user's device. Especially for a service that is intended to be used over untrusted networks, e.g. The Internet.

Could you please reassure me that it is just the documentation that is out of date? :)

[Guest]

A quick check with WIreshark reveals that SSL is indeed the only protection applied to the user's password, provided they use a https connection.

[PenkethBoy 2063]

yes this is correct - the password is plain text - md5 and sha was used in the past  but got dropped 

no idea why those choices were made - and yes its bonkers if you are using emby remotely even over a ssl connection

[Luke 36991]

7 hours ago, PenkethBoy said:

yes this is correct - the password is plain text - md5 and sha was used in the past  but got dropped 

no idea why those choices were made - and yes its bonkers if you are using emby remotely even over a ssl connection

It is standard industry practice to send "plaintext" passwords over HTTPS. The passwords are ultimately not plaintext, since the client-server communication is encrypted as per TLS.

 

[roaku 792]

Maybe I'm misunderstanding the OP's concern, but anything the *client side* could do to obfuscate the password before sending it to the server could be undone by anyone who bothered to peer into the javascript doing the obfuscating. So, the exercise is pointless. Only TLS or another transport encryption scheme can provide protection at that point.

The security issues come in in failing to transmit securely or the server *storing* the passwords in plaintext instead of salted/one way encrypted with only the ability to check for password matches by test encrypting the incoming text.

Edited December 18, 2020 by roaku

[Guest]

This turned out different than I expected. While looking for sources supporting my claim I was educated that things aren't as clear as I thought. First, one direct reply:

Quote

roaku: Maybe I'm misunderstanding the OP's concern, but anything the *client side* could do to obfuscate the password before sending it to the server could be undone by anyone who bothered to peer into the javascript doing the obfuscating.

The point of hashing is that it cannot easily be reverted. Hashing algorithms such as md5 are considered broken *because* there are rainbow tables available that allow (more or less) quick reverse lookups.

However, my train of thought aimed in another direction: I was thinking of deliberately slow hashing functions such as PBKDF2. The intention is to make obtaining the password hash to send to the server so slow that dictionary attacks become unfeasible. This seems to be not as common as I had assumed. (See this SO question.)

Another argument for client-side hashing would be that I don't trust the server - though why should I trust the Javascript *coming from the server* that hashes my password then? Well, tough.

The last one is protecting the user in case the server is compromised and the user reused the same password elsewhere. I didn't find a counter-curse for this one but if the passwords are *stored* as a salted hash on the server the attack becomes much more unlikely.

So it appears there are better reasons for server-side hashing than I expected and I learned a valuable lesson today.