PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
1–10 of 30 posts
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#2> When you visit the html webpage the key is in the hash property of the webpage, which is never sent to the server.
So it's only safe if you trust the server, which kind of defies the purpose?
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#3This is neat and has potential. But I was somewhat arrested by this feature:
"all pastes are cleared daily at 1:30am EST, so you have 12 hrs on average for your paste"
So, 12 hours on average... zero seconds if you're unlucky.
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#4This is neat and has potential. But I was somewhat arrested by this feature: " all pastes are cleared daily at 1:30am EST, so you have 12 hrs on average for your paste " So, 12 hours on average... zero seconds if you're unlucky.
Yeah, this is clearly a situation where average is not the most meaningful metric.
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#5> When you visit the html webpage the key is in the hash property of the webpage, which is never sent to the server. So it's only safe if you trust the server, which kind of defies the purpose?
[deleted]
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#6This is neat and has potential. But I was somewhat arrested by this feature: " all pastes are cleared daily at 1:30am EST, so you have 12 hrs on average for your paste " So, 12 hours on average... zero seconds if you're unlucky.
> zero seconds if you're unlucky.
Predictably unlucky by putting your paste in at 1:30 EST. But yeah, why not timestamp each record and give it a 24hr TTL?
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#7> When you visit the html webpage the key is in the hash property of the webpage, which is never sent to the server. So it's only safe if you trust the server, which kind of defies the purpose?
The command line version actually allows you to "not trust the server". But thinking it through I agree that the in-browser version could get served a different JS that grabs the hash and sends it to the server. This would be easily detectable, but it does seem like problem with the concept.
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#8> openssl enc blablabla
Don't use that line for encrypting stuff. There is no authentication and the IV is static. You're just asking for your secrets to be decrypted or modified without anyone noticing
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#9> When you visit the html webpage the key is in the hash property of the webpage, which is never sent to the server. So it's only safe if you trust the server, which kind of defies the purpose?
[deleted]
Re: PurritoBin: Ultra fast, minimalistic, encrypted command line paste-bin
#10> When you visit the html webpage the key is in the hash property of the webpage, which is never sent to the server. So it's only safe if you trust the server, which kind of defies the purpose?
The command line version actually allows you to "not trust the server". But thinking it through I agree that the in-browser version could get served a different JS that grabs the hash and sends it to the server. This would be easily detectable, but it does seem like problem with the concept.
> This would be easily detectable, but it does seem like problem with the concept.
I think it would be better to describe it as detectable but not practically so.
There have been many javascript "bitcoin wallet generators" that defrauded users this way. In both cases where they were backdoored from day one and cases where they changed the code later (sometimes on the fly based on useragent and referrer!) the detection has always been from users noticing their coins were stolen.
Its simply too difficult to review a javascript application given the ubiquity of deeply nested superfluous dependencies and toolkits-- and too pointless given that the code can be selectively substituted any any time, so almost no one does the review.