REST - SECURITY!!!

[VaughnRupp]

As Screens, WebUI, and other systems implement security to control internal access, REST leaves the whole system wide open to hackers. Shit, you don't even have to be a hacker, just have to know they use OSA and the API links.

I think user/pin at least can be added to the api url's. Not sure how to pass them or validate them, or make the mobile site use them, so it will be a bit of work, but from my limited understanding, it can be done, hell, it HAS to be done!

[VaughnRupp]

because of issues a couple people are having with rest, I am pushing this back a release or two until we get rest rock solid.

[KHerron]

Willing to look at this too!
The Mobile Site still uses a Login and has a Session that can be used.
However, instead of User/Pin it should be User/Password. At least I think.

Any other software using the REST plugin will need to implement a user login and validation, then use that to send to the REST API for Security.

[VaughnRupp]

There is the user, which is useful to pass in some calls for the Trust Level security, but it is plain text calls, so passing the name is ok, but password in the link might be a risk. But I think there is also a way to use HTTPS and secure the Rest calls with SSL or the such so the password can't be listened to. I thought someone has posted a ticket or forum message about that. I googles that a little, and saw articles on it, but I just moved on as it was too much to deal with at the time.

[KHerron]

Very True!! I was thinking of encrypting the username and password in to a 64bit string, but https would be a much cleaner approach.

[KHerron]

I have now setup an HTTPS://LocalHost. It does bring up my OSA, however I have a certificate error, and I'm not sure whats going on there. I think it has to do with it being Self-Signed or Encryption is outdated. Still trying to figure this one out. I think this will be our answer to the HTTPS issue.

[KHerron]

OK, It's the SHA1 in Google Chrome that has the issue.
HTTPS is working fine in IE.

[KHerron]

Based on my comments above, I was not fully understanding the structure of the REST plugin. It actually has nothing to do with the Web Server plugin or the Web UI. It basically runs independently. So realizing that, adding HTTPS to the web server is still something we should look in to, it would not solve the issue with securing the REST API.

As with the web server plugin, implementing HTTPS to REST would also be a nice approach, however I feel it would create a strain on the unfamiliar user when they would be required to create a "Self-Signed" certificate and then install it on their OSA machine. Also, this type of coding is a little beyond my comprehension, at the moment. I am still researching and learning what I can. But in the mean time, I feel anything we can do to improve the security of our servers, while still allowing us to enjoy the benefits of remote access and user control.

So, using AES-256 (Advance Encryption Standards with 256-bit encryption available through the Rijndael family class) I have created added the requirement of an AES-256 Encrypted Authentication key to be added to the end of all REST URL requests (GET and POST). The encrypted key contains 3 elements. Username, Time-Stamp & Password. Since the Time-Stamp changes every second, the authentication key will be different every second.

For higher security, using this type of encryption requires 2 keys that are used to Encrypt and Decrypt the Authentication key. These keys are never sent over the wire, and are only known by the OSA server and the Client using REST to access OSA. So, any devices or other applications that utilize the RESTful api to access OSA will be required to revise their code to implement these changes.

Each Client will have to have a way to store or retrieve the following information:

1. REST API Key - Any 32 character string. (example: KRIJqfnv18xfqcBs1cuNjzfs2RW5YWeJ)
2. System Security Key - Any 16 character string. (example: oemspial9uzpgzl8)
3. WAN/LAN IP Address or URL - Path to OSA Server. (192.168.1.xxx or http://myosa.noip.com)
4. Rest Port - Port OSA listens on for REST request. (Default: 8732)
5. User Name - OSA User name to use for Authintication (Johnathon)
6. User Password - OSA User Password to use for Authintication (MyP@$$w0rd)
7. TimeOffset - The number of hours your timezone is from GMT 000. (-5 for Eastern)

Since most devices or other applications that utilize the REST plugin are using or running javascript. I have created a nice little javascript to be used by developers to implement the new security encryption.

So far this is working perfectly with my Alexa Echo, as I have applied the security encryption to my Skill and have been testing for a few days now. I will work on applying these changes to the other parts of OSA that require it, and testing before I commit. This will probably require a few additions to the SQL, but I will try to handle that for you if I need to.

[KHerron]

OK, REST Security Update: I have now added the AuthKey required to ALL the REST request.
This will prevent anyone with a low Trust Level, not be able to GET information they shouldn't.
So, basically both POST and GET will require an AuthKey to be sent with the request.

Also, I have finished implementing the new REST security to the Web UI Screens.
Every time the Screen page refreshes, there is a new Authentication key generated.
The Generation is done "Server Side" to make it harder to decode what and how it is being encrypted.

I am thinking of moving the new Security code to it's OWN class: OSAESecurity
This will help referencing the exact same code from multiple places, and will reduce double coding.

Next I will look into the Screens Application, and get that section updated.
Also, I can look at the Android app, as I believe it uses the REST plugin too, but I'll be honest, I don't know that kind of coding.

Not sure what else uses the REST plugin, so if anyone knows of another plugin or application that is using the REST plugin to talk to OSA, please let me know and I can see what is needed to upgrade to the new security.

[KHerron]

This has been committed