Show HN: Onions.io – secure and open-source text storage in the cloud

You appear to be encrypting "Onions" with CBC with a static IV, using the hash of a string as the key, and with no integrity. You can't use a static IV. You can't encrypt without providing for authenticity. How do you know you don't have a padding oracle? The code you have right now will, from what I can tell, behave differently if an attacker modifies the ciphertext.

Where did the crypto design for this system come from?

Why are you hand-rolling your own crypto? Why didn't you use something like Nacl instead, which was already carefully designed to make crypto safe for developers that haven't studied the topic?

Two concerns:

1. Your security model is identical to that of Lavabit, and is equally vulnerable to you being legally compelled (and kept quiet with a gag order) to collect your user's passwords. What is your threat model?

2. On your "About" page, you explicitly state that your project has nothing to do with Onion routing. Then why name it onions.io? The domain name is similar to onion.to, a popular tor2web proxy. The logo is extremely similar to that of the Tor Project. This all seems like false advertising given that the project has nothing to do with those well-known concepts and projects. I would seriously considering changing the name and logo.

Don't forget the SSL config analysis -- you're not bad, but not up to the DuckDuckGo standard yet!

https://www.ssllabs.com/ssltest/analyze.html?d=onions.io

Generally agreed with other comments -- it's impossible to prove that the server is trustworthy (just imagine how easy it would be to tweak the server code to simply log all the cleartext that comes in...), so a purist approach forces you to encrypt on the client-side. On the other hand, a good & open server architecture, hosted somewhere the gov't can't oblige you to cheat, with external security audits goes a long way as well. Good usability and reliability often involve some security trade-off (think about password resets -- these are next to impossible if the server is untrusted!); the important thing is to figure out the best balance based on your intended customers.

Thinking more about the purist solution -- if the server is untrusted in your solution, you don't even need to provide the server anymore; let someone bigger handle that for you. I.e., you could generate a secure data file with your OSS client software (like KeePass or similar do), and let Dropbox or whoever else store it safely for you.

If you could make this really useable (incidentally, KeePass is not a good model here), that'd be a valuable creation. Unfortunately, then you're stuck building native applications for multiple platforms, which is probably not what you were hoping to be working on.

How do you prove that onions.io is running https://github.com/onionsapp/Onions-Rails-API?

A guy recently posted something similar written in Common Lisp called Turtl. [0] You might want to check that out as it avoids some of your design problems, namely "authentication" is really just entering the decryption key in your browser. All data is decrypted on the browser, and the host-proof service on the service knows none the wiser.

Also see Firefox Sync. [1] But I am seem to be one of five people who advocate it.

[0] https://github.com/turtl

[1] http://docs.services.mozilla.com/sync/

I know you say you're not storing the password on your end, but what prevents you (or a hacker who somehow gets access to your server) to suddenly start logging the passwords as they're sent to the server when someone logs in?

You've got what looks like a good approach to storing things in an encrypted way, but it's still requiring the user to trust that the server is actually doing what it says it's doing and no more.

I think it's great that people are trying to tackle this, and I feel a little sorry for the creator for some of the rather-harsh criticism. That said, given the nature and aim of the project, it really needs to live to very high standards to deliver on its promise. And some of those harsh-sounding words are to a large extent helpful. Putting things into perspective and helping identify the weak spots.

To me this looks similar (at least on the surface) to clipperz[1], even though I believe clipperz does all crypto on the client-side. Of course, both suffer from similar attack vectors or trust issues either way. Client-side does not mean you don't have to trust the server.

I hope for the sake of the project, that it gets more than just passing comments (however helpful), but rather serious engagement from people with experience in this field.

[1] https://github.com/clipperz/password-manager

This caught my attention, but then I read this:

"Things like passwords, debit card information or social security numbers lend themselves perfectly for Onions."

You can't be serious about that. Even if you could perfectly safely store SS numbers, don't even dare try to convince the public of that, they're going to think you're full of it instantly and the trust you require will be gone (deserved or not). You have to remember to account for the irrationality of people when you design a service, things they're scared of (even if they shouldn't be, and so on).

I'd argue that in general people don't feel great giving their SS number to the most secure companies on earth. Giving it to Onions.io? Forget about it. Don't go there unless you have the extraordinary reputation to overcome the fear people have about storing such sensitive info online.

I'm not being a hater, but tbere is a lot of "I'm not sure" in your answers.

Not the sort of thing that is reassuring to see from somebody claiming a solution is "secure".

That said, there is definitely a niche for this sort of app

The README throws up huge red flags to anyone who has studied crypto.

For example, saying you use AES-256 without explaining what cipher mode really doesn't say anything at all about the security of your system.

And even if your crypto system is awesome, it doesn't matter at all because it's all running on the server, where the NSA (or local equivalent) can simply force you to turn it off at any time.

If you really care about bringing strong privacy to users, you need to give them something they can run locally, so they don't need to trust your server.

The concept is flawed. You can never trust a 3rd party to not read your data; the only option is to run your own server.

Also for passwords you don't want the data to be permanent. Something like this would be better: https://github.com/badgerodon/selfdestruct.

Beta Codes:

  ebcc8d74-edee-46c6-a640-020741a9b2eb
  15ea4fa0-3ad6-46ea-a3b8-07136117f722
  64641c44-2d78-495d-b900-4534312f59be
  fdb92162-6de6-4868-b5f1-d5e1ba35516d
  c8d0fbb9-60c5-4156-92d2-8c9db48f1600
  e88a760e-7a4b-4ff2-9276-039d7630edd1
  59bd9776-ee53-401f-9d20-8a259a25007f
  80888b40-bce3-4d1d-a9ad-e555e5aaf37c
  5ed2e9e2-c152-4176-b7cb-aaf4700c4f4b
  2ab69676-c618-43bb-90fc-0353ceac756c
  a913abf4-5dbc-44ed-9e32-0b9ec08dd69d
  9cd734ff-e28e-42e4-95df-635f7d487dcc
  b4261b97-e6a9-4b10-a219-21f7b36913fc
  14d108b3-652b-4123-88f7-bdf8e3d87c04
  a8090aaa-b9ec-417f-9e62-98f0972587d4
  949c1467-40c1-4b93-bca8-97d80b756926
  b61fc80f-0f9e-45a9-82f3-61b0deaf52c9
  84b449d5-6b0b-4775-b4b0-531d50f25afc
  a09023fd-4ff2-4e8d-aabb-ee3c94dec08b
  806db2ef-42e3-46c6-901a-053da569561e
  4654e5c5-878a-4609-95c0-060f3ea81669
  21092de4-c521-4329-9bc7-1793dd3c1b4a
  4ea9e54c-cc31-40b4-bcf7-fadf75859964

i suggest you spend time looking at Persona so that users can just login with a Persona account without you warning them "well you have to remember a password".

I login with empty password. Just click login button.

Interesting idea. Some notes / comments / questions on the posted code (in no particular order):

* setting up a separate routing namespace for the API would clean up a number of things. In particular, it would make the web-only actions much clearer; calling respond_with with a JSON error payload and then relying on it to render the template (as done in OnionsController#index, for instance) is terribly confusing on a first read.

* does logging in actually set session[:UserKey]? It doesn't appear to, but that would make returning users unable to decrypt their existing onions.

* I really, really hope that isn't your actual session secret in config/initializers/secret_token.rb. More info on why this is bad and how to fix it here: http://blog.phusion.nl/2013/01/04/securing-the-rails-session...

* The encryption code in OnionsController would be better suited in the Onion model, especially since the decryption code is already there.

* the API for adding onions (OnionsController#addOnion) does not encrypt the data before storing it. Is this intentional?

* every action that modifies onions creates a new session. From the way that new_session works, I'm guessing this is to provide "session expiration" that's reset every time a user changes something. Would updating the timestamp on the user's existing Session accomplish the same thing, or have I missed something?

Some more code-review oriented notes:

* Some of your class methods in the models would be clearer as instance methods - for instance, both account_exists and pass_is_good take the hashed username as an argument and find the corresponding Account object. pass_is_good could be an instance method on Account. As another example, the code inside the loop in decrypted_onions_with_key could be an Onion instance method (telling an Onion object to decrypt itself vs. doing it externally).

* the comment character in Ruby is #, not surrounding things in / symbols (which creates a Regexp literal). In most cases (config/routes.rb, for instance) this happens to not cause problems - but it's still not a good habit to get into.

* some style notes: none of these affect the operation of your program, but they will affect how efficiently other developers read your code and work with it.

First, pick a tab setting in your editor of choice and stick with it. The "Ruby standard" is 2 spaces, but if you prefer something else at least be consistent.

Second, check out some of the Ruby style guides regarding naming. CapitalizedCamelCase is makes for somewhat odd-looking database column names.