Skytable use thoughts

Third Party Coronium
#1

Curious on your thoughts…

Using Skytable for users, I get it.

How about using it for app configuration and everyone reads it with the same ID? 

EG: Instead of username/id, you use ONE ID for the app, (User:MyBusinessApp@abc.com), base-BusApp and all users ONLY retrieve data, That way I can hold the App config in this table and retrieve it as needed.

I would then have an ‘admin’ user update (with another app) that updates this table. This would be the app owner only who updates the config.

Adding a quick flow for clarity. A quick powerpoint flow :stuck_out_tongue:

Good idea/Bad idea?

I would hate to go too far down the path to find its a bad idea!

Pros: 

Easy config retrieval in the app.

Hosted config allows for online updates

Can cache the results and pull new config if we update the version#

I could write user prefs out to a different ID if I want.

Cons:

If hacking the app exposes the ID/PW, is it really a concern? It will be read only for the released app. The editor app will be a desktop app.

Others?

#2

This sounds like a reasonable plan to me as long as the server is HTTPS.

Sure, it’s not 100% secure, but it isn’t terrible.

You can further secure it by encrypting or obfuscating any data you save in the table.  This will further help protect it when it goes over the wire and on the server.

-Ed

#3

Since it’s Skytable, the HTTP I assume is irrelevant since its the port 7173 (I think)

Obfuscating wouldn’t be a terrible idea at least for the amateur wandering eye :slight_smile:

I figure its about as secure as if I used PHP to pull the data back.

Thanks for the input.

#4

Whether the connection is secure (HTTPS) or in the clear (HTTP) totally makes a difference.

I’m unclear why the port is important.  Anyone who wants to scan the local area network for in the clear traffic your customers are using would easily capture data sent on any port.

#5

Hi,

You could certainly do this. And if you are just pulling data for the client, the id is less an issue.

To that note, I will be releasing a full featured data solution soon-ish, but of course it will not be as simple to use.

The server should use HTTPS, which can be done manually, but I will be automating it in the next couple days via an update pack.

-dev

#6

Yes, PULL only for the client.

I did look at the HTTPS, and did note that it failed. I took a look at the droplet, but this is somewhat out of my league.I’ll look forward to seeing a solution for that one :slight_smile:

A great job!

#7

Hi,

I’ve added the instructions on enabling HTTPS to the this forum as a separate post.

Let me know if you have any issues.

-dev

#8

@roaminggamer

Ed, what would you suggest for encrypting the data?

#9

@sporkfin,

  1. I would suggest using HTTPS connections only.

  2. If further security is required, the data can be obfuscated before sending and after retrieving using:

https://roaminggamer.github.io/RGDocs/pages/SSK2/libraries/security/

(This is a basic substitution-cipher encode/decode module).

  • OR -

One can use one of the libraries provided w/ Corona (or plugins) to encrypt/decrypt data.  However, once you do this, you need to mark your app as using encryption tech.  My  substitution-cipher module is the middle ground since it isn’t technically encryption.

#10

Hi,

+1 to everything @roaminggamer noted. 

Additionally, every SkyTable request is “signed” making it nearly impossible to recreate the request.

-dev

#11

@Develephant

I current use Coronium to upload and download JSON files.  Does SkyTable allow for data or just numbers and strings?

thanks,

Jonathan

#12

@roaminggamer

Curious, can I use SSK to obfuscate my data and then use SSK to obfuscate the key for the original obfuscation?  In other words, if I make a chain of keys, each obscured by your substitution-cipher module, would I be doing anything substantial or just making myself feel better?

#13

You can embed the key in your code to make it harder to find.  Then use the key to encode when uploading and decode when downloading.

I give an example of generating a key for embedding on the page linked above, but here is a direct link to the section:

https://roaminggamer.github.io/RGDocs/pages/SSK2/libraries/security/#embedding-a-key

Tip: Where you store your key is going to be a similar problem regardless of whether you use my module or another solution.

PS - You can also save/restore key to/from file, but I’m not talking about this above.

#14

As far as encoding a key with a different cipher.  Probably just a waste of time.

-Ed

#15

@roaminggamer What about saving the key to your keychain using the new Keychain plugin?   Your key would then be secure in a format native to your device so it would avoid tagging your app as an encrypted data user.

#16

As long as you don’t lose the original key it should be fine.  However, if you lose the key, you will out of luck for decrypting.

You could generate a key at run time

Save it on the keychain.

Use that key forever after.

#17

This sounds like a reasonable plan to me as long as the server is HTTPS.

Sure, it’s not 100% secure, but it isn’t terrible.

You can further secure it by encrypting or obfuscating any data you save in the table.  This will further help protect it when it goes over the wire and on the server.

-Ed

#18

Since it’s Skytable, the HTTP I assume is irrelevant since its the port 7173 (I think)

Obfuscating wouldn’t be a terrible idea at least for the amateur wandering eye :slight_smile:

I figure its about as secure as if I used PHP to pull the data back.

Thanks for the input.

#19

Whether the connection is secure (HTTPS) or in the clear (HTTP) totally makes a difference.

I’m unclear why the port is important.  Anyone who wants to scan the local area network for in the clear traffic your customers are using would easily capture data sent on any port.

#20

Hi,

You could certainly do this. And if you are just pulling data for the client, the id is less an issue.

To that note, I will be releasing a full featured data solution soon-ish, but of course it will not be as simple to use.

The server should use HTTPS, which can be done manually, but I will be automating it in the next couple days via an update pack.

-dev