Show HN: Duckist.com – Sharing Passwords Easily | Hacker News Reader

Show HN: Duckist.com – Sharing Passwords Easily

duckist.com

5 pointspinehqcom10 comments

"Messages are encrypted on the frontend". A non-technical reader might not know what a frontend is.

That's a good point. I'll find another way to express it. Thank you mtmail

"in your browser" is usually a good simple substitute.

Thanks Raed, We are changing it to "Messages are encrypted in your browser to ensure they are not even accessible to us" per your suggestion on Monday :)

Hey HN!

I am a part of a small IT business and like many of you, we face the constant problem with securely sharing passwords between clients and between coworkers. Of course, there are systems for this, but with busy schedules or mere complacency, it's a challenge to get all involved to set up these services accordingly. Failure to do so means that the passwords to accounts with critical user data often end up as contents of non-encrypted email messages or other equally unsafe means of communication. Confidential files share the same fate. We decided to take a different approach instead, which we think balances ease of use with security.

We named the service Duckist.com and with it, you can generate self-destructing messages containing either text or media, that are encrypted on the client-side. This means the server never actually sees the unencrypted message.

# Technical

This is only relevant if you'd like to know what's under the hood, which I know many of you guys here, certainly are :)

What we do is use the browser to create a password that is then used to encrypt the message on the client-side. The encrypted message is sent to the server and on the frontend side we generate a URL such as this:

https://duckist.com/msgs/messageID#password

How is that beneficial? When a person visits this URL, then the browser won't send anything the hash to the server. This means that when someone reads the message, Duckist.com never sees the password.

To see this is actually true, pop up the terminal with `netcat -l -p 9001` and input http://localhost:9001/hello#mysecret into your browser. You'll observe that `mysecret` was never sent to the server.

To see we are sending/receiving the messages encrypted you can use the browser's inspect functionality.

We saw the benefit of the tool's existence and decided to turn it into a public project hence I'd love to get your feedback. I am thick-skinned so just come at it in full HN style :)

This is actually an old project that we decided to rename, revive and improve. I previously wrote about it here: https://news.ycombinator.com/item?id=21513362

"If unclicked, the link will seize to be active in: week"

Maybe say "if not used" or "if not visited" or "Auto delete this message in ..."

Hey ibdf, great suggestions. I think the "If not visited delete after" is lot better wordwise!

Ps. what does your name stand for? ibdf?

initials

How do you encrypt on frontend?

Great question Freemade, we use https://crypto.stanford.edu/sjcl/ for the encryption. It is pretty straighforward. The password (as per my main message) is saved suffixced on the url with #. E.g. #mysecretpassword. This is because hashes are never sent to the server.

Reply on news.ycombinator.com