Jack Sarick posted an update

Security

There were a lot of security headaches with DYWTHM. Here is the basic interaction model:

When I started, we weren't using HTTPS and Bluetooth settings were horrible, and there were generally a ton of holes. These problems had to be handled in sections.

TL;DR I use HTTPS, Blowfish encryption, and best bluetooth practice. Pictures here

HTTP(S)

First problem was HTTP. I couldn't leave the connection insecure because we were transferring passwords. Step one was to re-write that part of the server. I wrote the server myself in node.js, using the default library. Luckily, node includes libraries for both HTTP and HTTPS communication. During dev, I used self-signed certificates on localhost, but when I pushed it to my site, I had to get real ones. Let's Encrypt makes this process free and relatively easy. Now the server was officially secure on that front Also, to prevent session hijacking, each request must be authenticated with a username and password.

Bluetooth

This was both a simple and a difficult problem. Bluetooth is a weird format to work with because it is a bit of a black box. I used to my advantage, and just fiddled with the default settings. Now the plush won't try to connect to anything once it has a partner. This helps guard against things like a spoofing attack.

Database/Server

The database was unpredictably fun to work with. It had a two big security holes: encryption and SQL injection. We used SQLite as a database so no unnecessary connections were made, and we could keep it fast and light. This was a huge plus, compared to my previous experience with MySQL. Unfortunately, the simple nature of SQLite databases means you can't simply protect them with a secure log in. I went back over my whole server, patching up holes I'd left open. Some key fixes:

  • Disabling password login (enforce SSH keys)
  • Can't SSH directly to root
  • Updating SSL to the most recent version

I also took into consideration how we store the information. One thing was basic database architecture. Because we have (hopefully) many users producing a lot of data, there is a chance that two things that should be unique are the same. This could be exploited by someone with malicious intent. To avoid this, I use auto-incremented ids instead of random so there's no unintentional collision. Another huge thing is my use of Blowfish encryption, probably the strongest general use encryption technique out there.

Log in or sign up for Devpost to join the conversation.