Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I created scrt.link

blog.stophe.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Why I created scrt.link

#21

Post by ALittleLight »

stophecom wrote: post #15
ALittleLight wrote: post #11

Earlier quoted context omitted.

I wonder if you could do the encryption entirely in the client so it was verifiably secure. Front end JavaScript generates a symmetric encryption key that is never shared to the server. User enters message. Message is encrypted with the generated key. You create the scrt sending only the ciphertext to the server which doesn't have the key and so couldn't read the message. You click a button to copy both the link to t…

It is done entirely on the client. You can check the source code. Read more on scrt.link/security.

But if the key is added to the link itself then you could be storing the encrypted string and decrypting it after getting a request for a link that contained the key.

I'm not accusing you of that - just saying there is no way to prove that's not happening.

Re: Why I created scrt.link

#22

Post by weird-eye-issue »

AndrewDucker wrote: post #19
weird-eye-issue wrote: post #16

Earlier quoted context omitted.

I use a similar service for when I need to share passwords in between the importance of a Netflix account and a production database. For example, if I need to give access to an assistant to access my ShutterStock account to avoid paying ShutterStock an additional $350/month. I don't want that password sitting in email because that just isn't good practice. But I also don't need a full blown team password management s…

If the link is sitting in their email then surely that's just as unsafe as having the password there?

No, it expires after they view it.

Re: Why I created scrt.link

#23

Post by stophecom »

ALittleLight wrote: post #21
stophecom wrote: post #15

Earlier quoted context omitted.

It is done entirely on the client. You can check the source code. Read more on scrt.link/security.

But if the key is added to the link itself then you could be storing the encrypted string and decrypting it after getting a request for a link that contained the key. I'm not accusing you of that - just saying there is no way to prove that's not happening.

The part of the URL holding the encryption key is not sent to the server. https://stackoverflow.com/questions/14462218/is-the-url-frag...

Don't take my word for it :) You can check all code that runs in your browser and check all requests made within the network tab.

Re: Why I created scrt.link

#24

Post by ALittleLight »

stophecom wrote: post #23
ALittleLight wrote: post #21

Earlier quoted context omitted.

But if the key is added to the link itself then you could be storing the encrypted string and decrypting it after getting a request for a link that contained the key. I'm not accusing you of that - just saying there is no way to prove that's not happening.

The part of the URL holding the encryption key is not sent to the server. https://stackoverflow.com/questions/14462218/is-the-url-frag... Don't take my word for it :) You can check all code that runs in your browser and check all requests made within the network tab.

Okay, nice! I withdraw my comments.

Re: Why I created scrt.link

#25

Post by [deleted] »

ALittleLight wrote: post #2

I just created and consumed a secret message. It seemed to work. Plus, I didn't have to create an account. Easy to use. I also love the name. I noticed in the FAQ you refer to your three secret types as text, redirect, and neogram. In other places you seem to call redirect "link". Could be a naming consistency fix. Features like delete after N visits or by X date might be useful too. I'm a little confused about the u…

[deleted]

Re: Why I created scrt.link

#26

Post by [deleted] »

mattowen_uk wrote: post #8
cunthorpe wrote: post #4

I’m always wary of consumer services that specifically target secrecy and encryption. How many of those “lockbox” photo apps are just syphons into the developer’s server? “We’ll encrypt the file, trust us.” This message can only come from an already-trusted party. Mozilla had an identical service to this except it was for files (Firefox Send) and that one I could trust.

If I wrote something like this, I'd try to be as transparent as I could be as to who I was, and how you could contact me. Hopefully that would create some small level of trust. -- As an aside, I know you are trying to be funny, but your username is tad offensive.

[deleted]

Re: Why I created scrt.link

#28

Post by jgalt212 »

weird-eye-issue wrote: post #22
AndrewDucker wrote: post #19

Earlier quoted context omitted.

If the link is sitting in their email then surely that's just as unsafe as having the password there?

No, it expires after they view it.

Yes, this is a nice solution, but email security services do click on links before delivering to the client's email inbox. As such, you may need to set the link expiry click number to greater than 1. And then you lose the security due to being ephemeral. Of course, you can log the IP addresses of the clickers, but still you have the leak.

Re: Why I created scrt.link

#30

Post by stophecom »

jgalt212 wrote: post #28
weird-eye-issue wrote: post #22

Earlier quoted context omitted.

No, it expires after they view it.

Yes, this is a nice solution, but email security services do click on links before delivering to the client's email inbox. As such, you may need to set the link expiry click number to greater than 1. And then you lose the security due to being ephemeral. Of course, you can log the IP addresses of the clickers, but still you have the leak.

> email security services do click on links before delivering to the client's email inbox

True. This may be a problem. Like mentioned, common bots are being blocked currently, plus, I will be testing POST instead of GET requests (Since bots apparently don't do POST). An another obvious solution is to include some kind of user interaction before the secret is fetched. Although I don't like that solution so much. C.

Post reply on HN