In your original comment, it seemed like you were suggesting hashing only before transmission
Ok, that wasn’t what I was suggesting, no. That would effectively make your password hash the password itself - and it would kinda be stored in PlainText on the server, if you skip the client auth and send that value to the server directly through the api or something
how does such a service (like Proton Mail) perform this in a web browser without having access to the data necessary to decrypt all of the data it’s sending? […] do you send down an encrypted private key that can only be decrypted with the user’s password?
Yes, pretty much. I can’t really find a good, detailed explanation from Proton how it exactly works, but LastPass uses the same zero-knowledge encryption approach - which they explained with some diagram here - with a good overview of the client/server separation of it’s hashing.
I’m not really sure how it opens up replay attacks, since it doesn’t really change anything to the default auth. There are already sites that do this.
The only difference is that instead of sending an http request of { username = “MyUsername”, Password = “MyPassword” } changes to { username = “MyUsername”, Password = HashOf(“MyPassword”) } - and the HashOf(“MyPassword”) effectively becomes your password. - So I don’t know how that opens up a possibility for replay attack. There’s not really any difference between replaying a ClearText auth request vs an pre-hashed auth request. - Because everything else server side stays the same
(Not entirely auth related), but another approach of client side decryption is to handle decryption completely client site - meaning all your data is stored encrypted on the server, and the server sends you an encrypted container with your data that you decrypt client side. That’s how Proton(Mail) works in a nutshell
there is no possible way to handle sensitive data without storing it in memory at some point
Since we’re nitpicking here - technically you can. They could run hashing client side first, and instead of sending the password in plain-text, you’d send a hashed version
I don’t know if there’s a “definitive guide” - it’s not that complicated to get a torrent client up and running. What kind of content are you looking for? Movies, Series, Music, Games, Books…?
Best is probably to try to get access to a decent private tracker, and an “easy” one - one with a bonus point system for seeding and uptime - that makes it much easier to keep a good ratio with a NAS, if you’re just permanently seeding everything you download, you’ll get points and “rise the ranks” of that tracker.
Once you’re a high enough rank on that tracker, you’ll get access to their “Invite Forums” where other private trackers advertise and give out invites to their trackers
What software/OS are you running on your NAS? If you’re running some goofy software on a private tracker your client might not be whitelisted.
Besides that - this NAS is attached to your home network I assume? Is it behind a router? Are the ports you’re using for torrenting port-forwarded?
What tracker are you testing this on? A bunch of trackers will have a “Connectivity check” that will tell you whether or not your client is connectable