Putting Access_Token to rest - inside the core - Most Secure

Getting Started
15

Ooh, I love a good security conversation!

There are lots of questions being posed here, so I’ll try to summarize and respond:

1.) What is the best / most secure way to control a core(s) / let users control their cores from my web app?

Storing your access_token in plain html or javascript on a public web page is not super secure unless you’re controlling access to that page, and your traffic to that page is encrypted with something like SSL.

The Cloud API supports a partial implementation of OAuth ( http://en.wikipedia.org/wiki/OAuth ), which we’re continuing to build out. OAuth provides a way for third party sites to let users request access to resources like your core, without giving away full control, or blindly trusting another site. This is widely used across the web, for example, think of any site that lets you “login via twitter/facebook/etc.”

I think the plan is to add controls so you can decide / disable access to third party sites and apps you’ve authorized. It’s the responsibility of those sites to securely control access to those special session tokens.

2.) What is the best / most secure way for my core to make a secure connection somewhere else directly?

The Core as an embedded environment, has limited resources. The secure connection it builds to the Cloud server is very resource intensive, but that is still less intensive / more optimized than your average HTTPS connection. We’ll be releasing the local cloud this summer which will let you have the same encrypted session with your core, and you can add any server-side code you like to make direct web requests on behalf of your core.

3.) Can I add a secondary layer of security on my core? Like a special password?

Totally! Fun idea! Although I’m not sure why this would be needed, you could definitely do something like create a spark function where the commands must always be preceded by a password. Something like:


setup() {
   Spark.function("whosthere", whosthere);
}

int whosthere(String command) {
  if (!command.indexOf("secretPassword!") != 0) {
    return -1;
  }
  //else secret stuff!
}

4.) On the business of cryptographic hashing schemes

As an amateur security nerd, I feel obligated to recommend you don’t use MD5 as a secure cryptographic hashing scheme. A cryptographic hashing scheme is only as good as it’s collision difficulty, and many of the older schemes are weakened or broken entirely. Many of the older schemes are also so easy to calculate now-a-days that rainbow tables exist to reverse engineer the saved values. http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms

5.) Brute forcing access_tokens

I don’t recommend testing our API ban hammer. The tokens are a big chunk of cryptographically secure random data that’s been cryptographically hashed and digested. If my math is right, each guess would be something like one in 1e48, and your requests will be slowed down and then cut off before making a dent in that space. That being said, I haven’t had someone try to test that yet, but again, please don’t do that. It would consume resources someone else could be building cool stuff with. If you want to brute force your access_tokens against your local cloud at home, then definitely go for it! :slight_smile:

Side note: We welcome advice or emails about security concerns you might find, and we sometimes reward responsible disclosure with free stuff! http://en.wikipedia.org/wiki/Responsible_disclosure – I love responsible disclosure, and welcome it!

Thanks,
David

6 Likes