(#3jlu4sa) @xuu Ah, cool!

(#3jlu4sa) @lyse there was an old tool for encrypted volumes that you could use random files as the unlock keys. And you could havemultiple hidden volumes that would unlock depending on the files supplied

(#3jlu4sa) @lyse there was an old tool for encrypted volumes that you could use random files as the unlock keys. And you could havemultiple hidden volumes that would unlock depending on the files supplied

(#3jlu4sa) @movq @xuu I see, the 5 GB video password seems like a superior strategy!

(#3jlu4sa) @movq You can always use a 5GB video file if the UI hashes it with SHA512 before posting to the server.

(#3jlu4sa) @movq You can always use a 5GB video file if the UI hashes it with SHA512 before posting to the server.

(#3jlu4sa) @lyse I can think of one use case for “password truncation”: Avoid DoS. There should be *some* limit to prevent you from using a base64 encoded 5 GB video file as a password. (Of course, that limit could be something like 1024 bytes instead of 20 bytes …)

(#3jlu4sa) @lyse Agreed 🤣

(#3jlu4sa) @prologic Yes, they all need to be burned down thoroughly.

(#3jlu4sa) @lyse You _do_ realize of course that there are numerous systems out there that _still_ to this day store passwords in the clear right? 😂 Shocking I know 🤦‍♂️