Sounds goods ! Just one small question inline
On Thu, Mar 13, 2014 at 12:59 PM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
Good morning slackers, moving forward with my attempt to put pants
on
passphrases. I would like to discuss how the REST API would be with the
change, because is better to have feedback instead of work for days and
waste some time.
Register push app:
- HTTP request
Remain unchanged
- HTTP response
{"id":"2095ab1a-a569-4ae2-a43c-a86b83041592",
"name":"MyApp",
"description":"awesome app",
"pushApplicationID":"ca99487d-6387-41bd-b393-0ce480977efe",
"masterSecret":"b315d524-e9f9-4d04-946c-b73278ff29be",
"developer":"admin",
"androidVariants":[],
"simplePushVariants":[],
"chromePackagedAppVariants":[],
"publicKey":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEpsPA31qRWrtiAhnpGBzgwoE435c18gD42y13urb0JSdx4AHQRthhAUFVnu+RqUU8NTp9tGnEEhyBZfbV67arVw==",
"nonce":"6KbYGZKvTusU+IL3sdY9g=="
"iosvariants":[]}
publicKey: Is the public key created per application and will be optional
for developers who do care about security. If for some reason they don't
want to encrypt their passphrase or certificate, that's ok.
nonce: 16 bytes non-deterministic used to encrypt the data on the server
Note: Both would be stored into UPS database (not perfect, but a good
start)
Keep in mind that this is just the initial idea, for example, masterSecret
should never return in clear. To the further interactions it will be fixed
establishing a key agreement between client and server and encrypt the
whole response (only for sensitive data). Yeah, I know, we are protected by
SSL, but we shouldn't trust on it.
iOS Variant:
- HTTP request
Remain unchanged, but now certificate and passphrase can be send
encrypted and the server will store it.
Shouldn't there be a flag in the request telling the cert and passphrase
are encrypted or not ? Or maybe the server can detect by itself if it's
encrypted or not .
- HTTP response
Remain unchaged
Sender:
- HTTP request
Remain unchanged, but now the server will search for the application ID
and retrieve the public key to decrypt application's passphrase
- HTTP response
Remain unchanged
AeroGear Clients
- cURL
Yesterday I had the amusing experience of dig into the sources of OpenSSL
and their documentation, to see how people could encrypt it from the
command line. If I recommend that people would remember my name for the
eternity in a bad way. Another insane idea was to provide encoders for GPG.
The simplest idea, I think, would be provide code for people encrypt their
passphrase and certificate, instead of trust in some software.
- aerogear-unifiedpush-java-client
No problem to implement it.
- aerogear-simplepush-java-client
No problem to implement it.
- aerogear-simplepush-node-client
Not so easy, but they do OpenSSL behind the scenes
- aerogear-unifiedpush-nodejs-client
Not so easy, but they do OpenSSL behind the scenes
So, what do you think? Yay/Nay? I would never use that?
The goal is to provide secure alternatives to developers, but if the whole
process will turn into a pain, I won't move forward.
--
abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev