5 ms·

Author here. This was a weekend project I've been working on. It's very much in beta. I'm using SJCL (https://crypto.stanford.edu/sjcl/ https://crypto.stanford

Author here. This was a weekend project I've been working on. It's very much in beta. I'm using SJCL (https://crypto.stanford.edu/sjcl/ https://crypto.stanford.edu/sjcl/) and CryptoJS (https://code.google.com/p/crypto-js/ https://code.google.com/p/crypto-js/) for client-side encryption, and Python's Cryptography library (https://cryptography.io/en/latest/ https://cryptography.io/en/latest/) for back-end encryption. Would love some feedback. Since it's in beta, signups are limited but you can use "hackernews500" as an early access code to sign up now if you want to check it out. Thanks! EDIT (PS - It's not mobile friendly yet, so you'll probably run into some UI issues on mobile devices)

jamestomasino 12y ago
It's interesting that you chose not to encrypt the titles of the entries. I suppose that's so that it's easier for us to browse back in time and find an entry without having to decrypt them all? Things I noted: - Each entry gets its own passphrase. You could use the same one again or again, or change it up. The addition of a 'hint' is nice. - The title default should clear when you enter it with your tab or mouse focus. That's a minor thing, but annoying. Regarding the keys used in the browser, is it possible to have whatever key phrase we enter also be seeded? That way, if by some miracle your database was compromised, anyone that did happen to use the same key passphrase over and over would have an extra level of protection? (Crypto people out there, does this actually give any additional protection, or am I just piling on unnecessary steps?)
- dylanbfox 12y ago
  Exactly. Some early feedback from friends said they needed more ways to find entries other than timestamps. Was thinking either titles or tags, and went with titles for now. Maybe I should make it more clear that titles aren't encrypted. It asks you for a new cipher key on every entry, correct. The encryption keys aren't stored. You could use the same cipher key for each entry though, and keep it in some password vault somewhere (maybe even on BitJournal itself). And leave a hint to remind you where the cipher key is.
  - jamestomasino 12y ago
    I really like it, dylanbfox. I think being more explicit on the titles would be a nice thing. My biggest question is where you see the future of this project going. Having a web-based home for my private journaling might be something I'd want, and the crypto seems nice. It does mean that there would never be a social aspect here that would grow a community in that regard. Ad serving for revenue is out because of the security implications. That leaves the question of what your plans are for hosting long term. You said this was a weekend project, and it's great, but if I were to start using this to store private information that I value, what sort of trust could I have that you'd keep the service going? Is it something you'd try to eventually monetize, or is this a candidate for open-sourcing so folks could self-host?
    - jamiesonbecker 12y ago
      I agree. Don't know what commercial plans you had for it, but I'd love to see something exactly like this as an open source single-page JS app that I could run as file:.. (this would help w/ pull reqs too).
      - dylanbfox 12y ago
        Thanks! I got a lot of great feedback yesterday that I'm incorporating, which is why I decided to pull the trigger and post to HN in the first place. For now I'm going to keep developing it as much as I can. I don't have any commercial plans. I thought about open sourcing it, and it's something I'm seriously considering. I do plan to host it for a while, but if for whatever reason I were to stop supporting it I would make this clear very far in advance. I should probably talk about this somewhere on the website. I'm sure other people have the same question. If you or anyone else has any other feedback/suggestions, please send it my way! My email is on the "info" page of the site. Thanks again.
  - deleted 12y ago
    [deleted]
peterwwillis 12y ago
Feedback: Browser crypto is unreliable. This has been debated to death, but here's a plain and simple fact: Your project delivers crypto software via your website to the user's browser, so this connection is absolutely critical for your site to be worth anything at all. And yours is not secure. First off, your root domain has no SSL server (https://bitjournal.io/ https://bitjournal.io/), so it's vulnerable to HSTS hijacking. Basically, if you use HSTS, someone can MITM the initial connection to http://bitjournal.io/ http://bitjournal.io/ every time because you don't have an SSL server on that hostname to negotiate HSTS. Fix: set up HSTS and an HTTP redirect on http://bitjournal.io/ http://bitjournal.io/ to https://bitjournal.io/ https://bitjournal.io/, set up HSTS and an HTTP redirect on http://www.bitjournal.io/ http://www.bitjournal.io/ to https://www.bitjournal.io/ https://www.bitjournal.io/, and then HTTP redirect from https://bitjournal.io/ https://bitjournal.io/ to https://www.bitjournal.io/ https://www.bitjournal.io/. Slightly more pressing problem: you aren't using HSTS at all. Anyone can mitm your site and screw with your users. Additional problem: your SSL site supports weak encryption, and is potentially vulnerable to secure renegotiation DoS. My suggestion is to do a lot more research into security in general before you get into making crypto software. You can fix the problems I mention above in a weekend, but that doesn't mean you won't make other mistakes which could expose your users' private data.
- sasas 12y ago
  Exactly my thoughts too. You would have thought that basic xss would be handled [1]. Downright irresponsible to tout a security product without due diligence. [1] http://imgur.com/DKmfic0 http://imgur.com/DKmfic0
- logicallee 12y ago
  gee, I'd hate to see what you have to say to the guy in this thread who made secretdiary.org which "was basically the same idea but implemented server-side", using php. in other words, relax, this is obviously a joke and not actually meant to be secure in any way, shape, or form.
  - akerl_ 12y ago
    "Keep your thoughts, ideas, and other confidential information protected from prying eyes with your own BitJournal. Each entry is encrypted with a symmetric key cipher, and only you have the key." Hopefully the author can comment, but this doesn't look like a joke.
signalsmith 12y ago
As others have mentioned, the JS for the crypto is fetched from the server every time, which is a weak spot because the server could give you duff crypto code. I've looked at similar things before, and I became very interested in Data URLs. Here's an example that PGP-encrypts files and uploads them to DropBox: https://bitbucket.org/geraintluff/encrypted-drop https://bitbucket.org/geraintluff/encrypted-drop The idea is that you can fit a very small implementation of SHA-256 as inline JavaScript in an HTML page. This means that you can produce a 1500-character Data URL which loads, SHA-256 verifies and executes the external resources needed to bootstrap your app. I started a whole module loader based on this concept, so you could do fancier things like async/parallel loading, adding more verification methods (e.g. public key, once that module is loaded) and so on: https://bitbucket.org/geraintluff/caution.js https://bitbucket.org/geraintluff/caution.js
- jamiesonbecker 12y ago
  That's pretty slick! (Let's assume that the PRNG in-browser issue is resolved.) Setting far-future expires/forcing long-term caching can help. Even LocalStorage for code can help. Of course, it's still chicken and egg -- and anything can be updated or disabled on the fly w/ HTML anyway at next load. Any of the injection or MITM issues that arise w/ in-browser crypto are similar to those in mobile apps or browser extensions as well, except that you have the chance to modify the app more often, so sticking your crypto code in an app or browser extension is no panacea anyway. Maybe you could combine this concept with http://headjs.com/ http://headjs.com/. It's a great idea.

jamestomasino 12y ago

It's interesting that you chose not to encrypt the titles of the entries. I suppose that's so that it's easier for us to browse back in time and find an entry without having to decrypt them all? Things I noted: - Each entry gets its own passphrase. You could use the same one again or again, or change it up. The addition of a 'hint' is nice. - The title default should clear when you enter it with your tab or mouse focus. That's a minor thing, but annoying. Regarding the keys used in the browser, is it possible to have whatever key phrase we enter also be seeded? That way, if by some miracle your database was compromised, anyone that did happen to use the same key passphrase over and over would have an extra level of protection? (Crypto people out there, does this actually give any additional protection, or am I just piling on unnecessary steps?)

dylanbfox 12y ago
Exactly. Some early feedback from friends said they needed more ways to find entries other than timestamps. Was thinking either titles or tags, and went with titles for now. Maybe I should make it more clear that titles aren't encrypted. It asks you for a new cipher key on every entry, correct. The encryption keys aren't stored. You could use the same cipher key for each entry though, and keep it in some password vault somewhere (maybe even on BitJournal itself). And leave a hint to remind you where the cipher key is.
- jamestomasino 12y ago
  I really like it, dylanbfox. I think being more explicit on the titles would be a nice thing. My biggest question is where you see the future of this project going. Having a web-based home for my private journaling might be something I'd want, and the crypto seems nice. It does mean that there would never be a social aspect here that would grow a community in that regard. Ad serving for revenue is out because of the security implications. That leaves the question of what your plans are for hosting long term. You said this was a weekend project, and it's great, but if I were to start using this to store private information that I value, what sort of trust could I have that you'd keep the service going? Is it something you'd try to eventually monetize, or is this a candidate for open-sourcing so folks could self-host?
  - jamiesonbecker 12y ago
    I agree. Don't know what commercial plans you had for it, but I'd love to see something exactly like this as an open source single-page JS app that I could run as file:.. (this would help w/ pull reqs too).
    - dylanbfox 12y ago
      Thanks! I got a lot of great feedback yesterday that I'm incorporating, which is why I decided to pull the trigger and post to HN in the first place. For now I'm going to keep developing it as much as I can. I don't have any commercial plans. I thought about open sourcing it, and it's something I'm seriously considering. I do plan to host it for a while, but if for whatever reason I were to stop supporting it I would make this clear very far in advance. I should probably talk about this somewhere on the website. I'm sure other people have the same question. If you or anyone else has any other feedback/suggestions, please send it my way! My email is on the "info" page of the site. Thanks again.
- deleted 12y ago
  [deleted]

peterwwillis 12y ago

Feedback: Browser crypto is unreliable. This has been debated to death, but here's a plain and simple fact: Your project delivers crypto software via your website to the user's browser, so this connection is absolutely critical for your site to be worth anything at all. And yours is not secure. First off, your root domain has no SSL server (https://bitjournal.io/ https://bitjournal.io/), so it's vulnerable to HSTS hijacking. Basically, if you use HSTS, someone can MITM the initial connection to http://bitjournal.io/ http://bitjournal.io/ every time because you don't have an SSL server on that hostname to negotiate HSTS. Fix: set up HSTS and an HTTP redirect on http://bitjournal.io/ http://bitjournal.io/ to https://bitjournal.io/ https://bitjournal.io/, set up HSTS and an HTTP redirect on http://www.bitjournal.io/ http://www.bitjournal.io/ to https://www.bitjournal.io/ https://www.bitjournal.io/, and then HTTP redirect from https://bitjournal.io/ https://bitjournal.io/ to https://www.bitjournal.io/ https://www.bitjournal.io/. Slightly more pressing problem: you aren't using HSTS at all. Anyone can mitm your site and screw with your users. Additional problem: your SSL site supports weak encryption, and is potentially vulnerable to secure renegotiation DoS. My suggestion is to do a lot more research into security in general before you get into making crypto software. You can fix the problems I mention above in a weekend, but that doesn't mean you won't make other mistakes which could expose your users' private data.

sasas 12y ago
Exactly my thoughts too. You would have thought that basic xss would be handled [1]. Downright irresponsible to tout a security product without due diligence. [1] http://imgur.com/DKmfic0 http://imgur.com/DKmfic0
logicallee 12y ago
gee, I'd hate to see what you have to say to the guy in this thread who made secretdiary.org which "was basically the same idea but implemented server-side", using php. in other words, relax, this is obviously a joke and not actually meant to be secure in any way, shape, or form.
- akerl_ 12y ago
  "Keep your thoughts, ideas, and other confidential information protected from prying eyes with your own BitJournal. Each entry is encrypted with a symmetric key cipher, and only you have the key." Hopefully the author can comment, but this doesn't look like a joke.

signalsmith 12y ago

As others have mentioned, the JS for the crypto is fetched from the server every time, which is a weak spot because the server could give you duff crypto code. I've looked at similar things before, and I became very interested in Data URLs. Here's an example that PGP-encrypts files and uploads them to DropBox: https://bitbucket.org/geraintluff/encrypted-drop https://bitbucket.org/geraintluff/encrypted-drop The idea is that you can fit a very small implementation of SHA-256 as inline JavaScript in an HTML page. This means that you can produce a 1500-character Data URL which loads, SHA-256 verifies and executes the external resources needed to bootstrap your app. I started a whole module loader based on this concept, so you could do fancier things like async/parallel loading, adding more verification methods (e.g. public key, once that module is loaded) and so on: https://bitbucket.org/geraintluff/caution.js https://bitbucket.org/geraintluff/caution.js

jamiesonbecker 12y ago
That's pretty slick! (Let's assume that the PRNG in-browser issue is resolved.) Setting far-future expires/forcing long-term caching can help. Even LocalStorage for code can help. Of course, it's still chicken and egg -- and anything can be updated or disabled on the fly w/ HTML anyway at next load. Any of the injection or MITM issues that arise w/ in-browser crypto are similar to those in mobile apps or browser extensions as well, except that you have the chance to modify the app more often, so sticking your crypto code in an app or browser extension is no panacea anyway. Maybe you could combine this concept with http://headjs.com/ http://headjs.com/. It's a great idea.