Guest Posted December 17, 2020 Share Posted December 17, 2020 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? :) Link to comment Share on other sites More sharing options...
Guest Posted December 17, 2020 Share Posted December 17, 2020 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. Link to comment Share on other sites More sharing options...
PenkethBoy 2063 Posted December 18, 2020 Share Posted December 18, 2020 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 Link to comment Share on other sites More sharing options...
Luke 37128 Posted December 18, 2020 Share Posted December 18, 2020 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. Link to comment Share on other sites More sharing options...
roaku 797 Posted December 18, 2020 Share Posted December 18, 2020 (edited) 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 1 Link to comment Share on other sites More sharing options...
Guest Posted December 18, 2020 Share Posted December 18, 2020 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now