Code your own authentication system

[khinester]

Is it possible to code your own authentication system in GAE and
either allow users to login via the their own google account or if
they don't have the can register on my application and then access it
this way.

Cheers
Norman

[peterk]

You can certainly code your own authentication system.

Mixing it with the Google system..I guess you can, I guess it would be
a matter of directing new member data to your own User model, and then
when logging in, checking with google's system, and then if no member
found, checking with your own.

[Paolo]

On Jun 24, 9:48 am, peterk <peter.ke...@gmail.com> wrote:

> You can certainly code your own authentication system.

Since there is no SSL/TLS support, and probably never will be, any
other authentication system will not be secure. I think that anyone
that needs another authentication system needs to consider another
hosting service.

[peterk]

This is a fair point. But I think SSL support will have to come.

I do know also that some (big!) apps don't use SSL on their
logins..maybe they should, but in reality some don't :) Some API
services (that use user/pass auth) don't use it either, or at least
don't require clients to use it, because they can't guarantee all
their clients will be able to make requests over https.

[javaDinosaur]

> Since there is no SSL/TLS support, and probably never will be

If true I am going to burn my Python books and get back to programming
Java on an Amazon EC2 VM.

Why do you predict no SSL?

[peterk]

I think it has to come with the billed version of the system (and
hopefully that is very soon!)

They know they can't support the next big thing on the platform
without it, really. An app might get away without it while it's
relatively unknown, but the bigger an app gets, the more likely it is
someone might start snooping around looking for vulnerabilities.

Certainly, if I thought it wasn't coming, or if it was many months
away, I'd probably have to join you at that book burning and make
alternative arrangements :|

It'd be really nice if Google could give us a roadmap.

[Paolo]

On Jun 24, 11:54 pm, javaDinosaur <jonathan...@hotmail.co.uk> wrote:

> > Since there is no SSL/TLS support, and probably never will be
>
> If true I am going to burn my Python books and get back to programming
> Java on an Amazon EC2 VM.

You could use any Python framework on EC2 too, and you would not have
to deal with AppEngine limitations. What you would miss is BigTable
and the load computation based on your site load as opposed to the
actual time your machines are powered on.

> Why do you predict no SSL?

AFAIK there has been no official comment about it (PLEASE, tell me I
missed it!). I will explain why I think AppEngine will never support
SSL for custom domains (perhaps they will implement it for appspot).

Let's start noting that every AppEngine application is served by a
cloud of web servers, so there is no IP associated with a single
application. Currently, without RFC 4366 [1][2], TLS does not provide
a mechanism for a client to tell a server the name of the web site it
is contacting; that is contained only in the Host HTTP header, to be
sent AFTER the SSL link has been estabilished. The bottom line is that
without RFC 4366, a web server does not know which certificate to use
to encrypt the connection.

Moreover, when a web browser tries to contact yourdomain.com, it is
redirected to ghs.l.google.com (only if not registered through Google)
and then to a web server in their server cloud like ik-in-
f121.google.com (always, not just for other registrars' domains).
Since the requested domain does not match the one that served your
request, you will get a certificate failure. You can try this simply
pointing your browser to https://appgallery.appspot.com/ :

appgallery.appspot.com uses an invalid security certificate.
The certificate is only valid for the following names:
google.com , *.google.com

The only way that I see to make it work, is for Google to configure
their DNS to redirect the requests to something in the form varying-
serverid.yourdomain.com for every custom domain and every server in
the appengine cloud, and this is unlikely to happen.

I would love to see HTTPS supported by AppEngine, but unless Google
announces it, I am not going to delude myself. I really hope someone
can prove I am wrong.


Paolo


.. [1] Transport Layer Security Extensions allow clients to include
the host name in the extended client hello, but currently implemented
by Opera, MSIE 7 (under Vista only), and Firefox 2+ (http://
www.ietf.org/rfc/rfc4366.txt)
.. [2] Name-based SSL virtual hosts: how to tackle the problem (http://
www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf)

[peterk]

I think mentions of SSL from Google were that it's not "currently"
supported. I'm not sure if they've gone beyond that yet. It would be
VERY helpful if they could clarify this. They kind of solidified the
pricing range for the service not so long ago even though the billing
service is not here yet, and I think a feature like SSL should be the
next thing they clarify, even if it won't be immediately available.

This might be a naive question, but in the meantime are there some
more creative solutions for at least protecting authentication
information?

For example, HTTP Digest for protecting passwords at least?

Or with form based login, perhaps a custom public-key encryption
mechanism using javascript to encrypt details on the client side (and
then your own code on the server side to decrypt)?

I know this isn't going to protect all data passing between client and
server, but keeping passwords safe might be enough for many.

> pointing your browser tohttps://appgallery.appspot.com/:

[javaDinosaur]

Thanks Paolo, I understood most of your post.

Previously I assumed that because Amazon had managed to do SSL with
their "elastic" IP addresses. I thought Google had similar options.
But now I realize that an Amazon EC2 instance is a fixed single point
of reference once loaded.

For me, https support on *.appspot.com would be good enough for the
first year of AppEngine's commercial operation. I could explain away
the appspot domain to my entry level SaaS customers.

If SSL support is not confirmed by October I will have to recode my
server-side logic in Java and host on Amazon's EC2 cloud.

For the moment +50% of my development effort is focussed on creating a
rich JavaScript UI so this will not go to waste. In a perverse way I
am finding that designing to the limitations of Python and AppEngine
is therapeutic and results in improved development productivity. I
tend to over design when given the no-limits potential of a 2Gb Java
JVM coupled to an advanced relational database.

[Paolo]

On Jun 25, 12:42 pm, Filip <filip.verhae...@gmail.com> wrote:

> Except for RFC 3546 section 3.1 (TLS SNI), already supported by IE 7,
> Firefox, and Opera.

RFC 3546 3.1 covers TLS SNI exaclty as RFC 4366 3.1 does, isn't it?

I tested it on https://sni.velox.ch/ with Internet Explorer 7 on
Windows XP SP3, and it is not working. How did you test it? The only
reference I found that confirms what you said is Wikipedia.

Thanks,
Paolo

[Barry Hunter]

Umm, no they dont. They use a DNS CNAME - but that is transparent to
the end user and browser (where certificate negotaion happens)

> Since the requested domain does not match the one that served your
> request, you will get a certificate failure.

It fails becuase the domain on the certificate *.google.com doesnt
match ourdomain.com

(the dns names used in between are irrelivent)

> You can try this simply
> pointing your browser to https://appgallery.appspot.com/ :

Google have just implemented a redirect away because it doesnt work.

>
> appgallery.appspot.com uses an invalid security certificate.
> The certificate is only valid for the following names:
> google.com , *.google.com
>
> The only way that I see to make it work, is for Google to configure
> their DNS to redirect

DNS cant do redirects. Redirects could be implemented by the final
webserver pointed at by the DNS

> the requests to something in the form varying-
> serverid.yourdomain.com for every custom domain and every server in
> the appengine cloud, and this is unlikely to happen.

They could do one of two things

* Allow clients to purchase certificates and install them on the
servers so that yourdomain.com could work - this would add significant
overhead IMHO - and is reliant on the browser sending the host header
as mentioned in those RFCs

* setup a certificate for *.appspot.com and any https connections to
yourdomain.com could be redirected to your appspot subdomain

>
> I would love to see HTTPS supported by AppEngine, but unless Google
> announces it, I am not going to delude myself. I really hope someone
> can prove I am wrong.
>
>
> Paolo
>
>
> .. [1] Transport Layer Security Extensions allow clients to include
> the host name in the extended client hello, but currently implemented
> by Opera, MSIE 7 (under Vista only), and Firefox 2+ (http://
> www.ietf.org/rfc/rfc4366.txt)
> .. [2] Name-based SSL virtual hosts: how to tackle the problem (http://
> www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf)
> >
>

--
Barry

- www.nearby.org.uk - www.geograph.org.uk -

[Paolo]

On Jun 25, 2:10 pm, "Barry Hunter" <barrybhun...@googlemail.com>
wrote:

> DNS cant do redirects. Redirects could be implemented by the final
> webserver pointed at by the DNS

Yes, my fault. With "DNS redirect" I meant "DNS CNAME record". Thanks
for the correction.

> They could do one of two things
>
> * Allow clients to purchase certificates and install them on the
> servers so that yourdomain.com could work - this would add significant
> overhead IMHO - and is reliant on the browser sending the host header
> as mentioned in those RFCs

IMO the lack of client side support is the main issue here.

> * setup a certificate for *.appspot.com and any https connections to
> yourdomain.com could be redirected to your appspot subdomain

And this means not supporting https for custom domains.

[Filip]

On 25 jun, 15:30, Paolo <paolo.ambro...@data-14.com> wrote:
> On Jun 25, 2:10 pm, "Barry Hunter" <barrybhun...@googlemail.com>
> wrote:
>
> > DNS cant do redirects. Redirects could be implemented by the final
> > webserver pointed at by the DNS
>
> Yes, my fault. With "DNS redirect" I meant "DNS CNAME record". Thanks
> for the correction.
>
> > They could do one of two things
>
> > * Allow clients to purchase certificates and install them on the
> > servers so that yourdomain.com could work - this would add significant
> > overhead IMHO - and is reliant on the browser sending the host header
> > as mentioned in those RFCs
>
> IMO the lack of client side support is the main issue here.

Actually, most current browsers already have this functionality on by
default: IE 7, Firefox 2 and 3, Opera 9. If you are using any of these
browsers, you already comply to the RFC (at least the SNI portion of
it). The notable exception to date is Safari.

I don't believe this would have significant overhead, relative to a
certificate for *.appspot.com.

[Filip]

Right, I don't have IE 7 here right now, but that test site works well
in Firefox 3.

On their site, I read the following browser support SNI:
* Opera 8.0 and later (the TLS 1.1 protocol must be enabled)
* Internet Explorer 7 (under Windows Vista only, not under Windows
XP)
* Firefox 2.0 or later
* Curl 7.18.1 or later (when compiled against an SSL/TLS toolkit
with SNI support)

Notice the XP bit.

Filip.

On 25 jun, 13:39, Paolo <paolo.ambro...@data-14.com> wrote:
> On Jun 25, 12:42 pm, Filip <filip.verhae...@gmail.com> wrote:
>
> > Except for RFC 3546 section 3.1 (TLS SNI), already supported by IE 7,
> > Firefox, and Opera.
>
> RFC 3546 3.1 covers TLS SNI exaclty as RFC 4366 3.1 does, isn't it?
>

> I tested it onhttps://sni.velox.ch/with Internet Explorer 7 on

[khinester]

Thanks for all the responses.

So the issue here is that in order for authentication to work users to
an apps site must have a google account.

I currently have my emails for my own domain hosted by google, but the
authentication does not work when I try to access my apps using this
account, but this is on google server?!?

It will be great for intranet type application if the authentication
mechanism was coupled with the http://www.google.com/a/doman.com
accounts

The URI for the logins are:

https://www.google.com/accounts/ServiceLoginAuth?service=ah&sig=XXX

https://www.google.com/a/domain.com/ServiceLogin?service=CPanel&continue=XXX

What do you all think? Does it make sense?

[peterk]

Strictly speaking I wouldn't say must have a google account, but it is
probably the easiest way.

You can authenticate users with your own scheme and send
authentication information 'in the clear'. Lots of sites do this, if
the security of your data isn't absolutely critical you'd probably get
away with that.

Your second option, if for example your running an API-service, might
be HTTP Digest authentication... I haven't tried it yet. I know HTTP
Basic works for sure though. But if Digest works also, you could use
that to secure API calls whilst also protecting your user's passwords.

Finally, with form-based logins there still might be the potential to
roll your own encryption if you don't want to send that information in
the clear, as I mentioned in my previous post. Again, though, I have
not implemented this myself and I'm not entirely sure how feasible it
is..but it would probably be more secure again vs HTTP Digest. If
anyone has any comments on whether that'd be worth one's while or not,
I'd be interested to hear.

[Canis]

On Jun 25, 4:33 pm, peterk <peter.ke...@gmail.com> wrote:

> Your second option, if for example your running an API-service, might
> be HTTP Digest authentication... I haven't tried it yet. I know HTTP
> Basic works for sure though. But if Digest works also, you could use
> that to secure API calls whilst also protecting your user's passwords.

I've found HTTP Digest to be unreliable -- there seems to be some
ambiguity in the spec, and some browsers/servers implement it slightly
differently. This tends to manifest itself as your browser randomly
'forgetting' your credentials and asking you to log in again (in
reality, the server has just spontaneously decided your login is
invalid and demanded fresh ones).

HTTP Basic over SSL is simpler and works on everything -- if you have
SSL, of course.

> Finally, with form-based logins there still might be the potential to
> roll your own encryption if you don't want to send that information in
> the clear, as I mentioned in my previous post. Again, though, I have
> not implemented this myself and I'm not entirely sure how feasible it
> is..but it would probably be more secure again vs HTTP Digest. If
> anyone has any comments on whether that'd be worth one's while or not,
> I'd be interested to hear.

Well, it depends on how paranoid you are. :)

One problem is that the browser has to get the javascript encryption
code from somewhere. Without SSL, you can't guarantee the security of
that code itself! It could do anything...

It does, at least, raise the level of attack required from passive
(monitor communications only) to active (intercept/modify/inject
traffic). This might be enough to put attackers off -- but if you
were, for example, using a public WiFi access point, it's quite
feasible for the AP owner to modify traffic as it passes through (eg
http://www.ex-parrot.com/~pete/upside-down-ternet.html ). Like I say,
it all depends on how paranoid you are, and whether anyone can
actually get benefit from hacking your app.

Plus, as always, there's the issue of distributing/exchanging keys.

I'm working on an application that has two ways to access it: via
regular web-browser, and via a desktop app.

The desktop app is the reason I can't use Google accounts for my app.
I'm not comfortable with (and nor is it good practice) asking users to
enter their Google account details into my desktop app, especially
when you consider how many different things that password unlocks
these days.

(I really encourage other people not to do this either -- it would
just be creating a long-term phishing disaster.)

So, I've put together a simple 'secure session' system that does no
encryption, but it _does_ sign every packet for authenticity, and uses
that instead of logging-in the traditional way. The sessions don't
contain sensitive data, I just want to prevent Bad Guys(tm) from
accessing the service without an account, or trashing someone else's
account.

So instead of saying, "Hi, I'm user Canis password Seekrit" and, then,
once logged in, saying "I want to modify some data now", the client
would simply say, "Hi, Canis wants to modify some data pls kthxbye.
<signature>" where <signature> is a sha1 hash of (Canis, Seekrit,
modify-some-data, sequence number).
The sequence number is to avoid replay attacks -- you can skip
sequences (to account for dropped connections) but you can never go
back. The server verifies all this stuff at the other end.

(I actually go a bit further than this to avoid chosen-plaintext/
forced-hash-collision dubiousness, but that's the gist of it. I
probably shouldn't worry so much, but what can I say? I read a lot of
Schneier when I was young... :P )

It works pretty well, but there are two problems at the moment:

1. Currently, there isn't really a secure way to _set up_ an account.
The server needs to know the correct password somehow. You can do it
from home, though, over your hopefully-more-secure personal
connection, then know that you're 'safe' when out-and-about on WiFi,
which is an improvement.

2. There's no graceful way to integrate this with the non-desktop
version -- how does a user log into the web app securely?

Now, we can solve 1. by using Real Crypto(tm) -- the server has a
private key, the public key is embedded into the desktop app (which is
distributed securely), and then we're ready to rock.

(This _could_ replace the whole digest system I described above, but
applying public-key crypto to every request is going to incur
significant overhead. You can encrypt a session key of course, but
really, we're getting into "re-implementing SSL from scratch"
territory here, which we're bound to do worse -- slower and less
securely -- than real SSL. I don't recommend it).

The catch is that all the crypto libraries I can find for Python are C
extension modules, so we'd need to persuade Google to add one for us.
This seems like a useful thing for them to support, though, and
probably requires less infrastructure-hackery on their part, to get a
useful end result, compared to SSL.

Failing that, recommendations for a good, pure-Python asymmetric
crypto library are welcome :)

Now, how to solve problem number 2? Maybe serve the javascript off a
non-Google, SSL-secured site, that does that and nothing more? With a
nice long cache time, this should be pretty cheap if you shoved it in
an S3 bucket. This is my current plan, but I'd love a better one. It's
still a slow/gronky method though, if you ask me. Sucks for anyone non-
JS-enabled too.

This also points out another approach to the creating-new-accounts
problem: The client SSL's to an offsite server, which already has
credentials with the AppEngine site. The SSL server doesn't need to be
massively scalable -- although it's a choke-point, it's only on new
account creations, it should only ever get one request _ever_ per user
of your system.

Anyway, enough of me thinking out loud. Hope some of that's of use.

-c

[Barry Hunter]

When creating the app engine account you can choose to authenticate
against a hosted domain

---------
Restricted to the following Google Apps domain:
e.g. foo.com
If your application uses authentication, only members of this Google
Apps domain may sign in. If your organization uses Google Apps, use
this option to create an application (e.g. an HR tracking tool) that
is only accessible to accounts on your Google Apps domain. This option
cannot be changed once it has been set.
---------

You can choose this at setup its not possible to change afterwards.

There is no equivent on the SDK but it works functionally the same
from the App point of view anyway.

--

[peterk]

Thanks Canis for your very comprehensive post :) I'll probably come
later when I get a chance to think about this more, but just a couple
of small points for now..

> I've found HTTP Digest to be unreliable -- there seems to be some
> ambiguity in the spec, and some browsers/servers implement it slightly
> differently. This tends to manifest itself as your browser randomly
> 'forgetting' your credentials and asking you to log in again (in
> reality, the server has just spontaneously decided your login is
> invalid and demanded fresh ones).

Server side issues could be a problem here. But the context for HTTP
Digest that I was thinking of was if running an API service. Your
clients wouldn't be browsers (typically), but other pieces of code
elsewhere, so you could have more precise control over the client side
of the equation. As for the server forgetting credentials, this
wouldn't be such a big deal where you are authenticating each API
request anyway...(?)

I was thinking of using Digest for my API requests, and then a custom
JS encryption scheme for my form based logins on the 'interface site'
if you like. But..

> One problem is that the browser has to get the javascript encryption
> code from somewhere. Without SSL, you can't guarantee the security of
> that code itself! It could do anything...

..this is true. But, I like your idea about hosting your JS on a third
party host with SSL.. would this cover your back here?

If this would be sufficient for protecting passwords, that would keep
me ticking over until Google provides SSL. It wouldn't protect my data
being read by someone (i.e. data passed around in API requests), but
it would stop them getting the credentials needed to alter the data..
(or would it? hehe. i hope at least).

I suppose the other big problem of rolling your own is making a
mistake and having a vulnerability in your scheme. A tested standard
like SSL has that advantage. Though maybe we could offer up a JS-based
form encryption scheme that could be stress-tested by the community
here (if one doesn't already exist).

>
> The desktop app is the reason I can't use Google accounts for my app.
> I'm not comfortable with (and nor is it good practice) asking users to
> enter their Google account details into my desktop app, especially
> when you consider how many different things that password unlocks
> these days.
>

Just a small point..I thought I read in some book somewhere that
Google had a way to direct users to their login pages even within
other applications asides from the browser (so the user doesn't have
to trust you with their google credentials).. can't remember the
entire details..but I'll post if I find it again.

I will come back to study your whole post later, and no doubt I will
have questions again on things I might apply in my own system :)
Thanks again for your post!

[Canis]

On Jun 25, 7:34 pm, peterk <peter.ke...@gmail.com> wrote:

> Server side issues could be a problem here. But the context for HTTP
> Digest that I was thinking of was if running an API service. Your
> clients wouldn't be browsers (typically), but other pieces of code
> elsewhere, so you could have more precise control over the client side
> of the equation.

Ah, this is true in that case, yes. If you completely control the
client, and can match it to the server's behaviour, Digest is fine.

(By API, I thought you were talking about AJAX in the browser, which
would of course be your JS code, but subject to the browser's whim as
to how it handles the http connection.)

> As for the server forgetting credentials, this
> wouldn't be such a big deal where you are authenticating each API
> request anyway...(?)

It's not actually forgetting them, it spontaneously decides they're
invalid because they interpret the spec differently. I think it has
something to do with timestamps, but I don't actually remember -- I do
know that when I asked Apache to Digest-protect a website, then
visited it in Safari, whenever it asked me for my password again, the
server error logs were full of complaints about time-travel! :)

With HTTP Digest, you can't issue a valid request "out of the blue" --
each client request depends on information supplied by the server in
the initial 401 Unauthorised response. So starting authentication from
scratch each time would double your HTTP requests, roundtrips, latency
etc...

> ..this is true. But, I like your idea about hosting your JS on a third
> party host with SSL.. would this cover your back here?

I believe so. I'm willing to be corrected :)

> If this would be sufficient for protecting passwords, that would keep
> me ticking over until Google provides SSL. It wouldn't protect my data
> being read by someone (i.e. data passed around in API requests), but
> it would stop them getting the credentials needed to alter the data..
> (or would it? hehe. i hope at least).

Depends on your authentication algorithm :)

> I suppose the other big problem of rolling your own is making a
> mistake and having a vulnerability in your scheme. A tested standard
> like SSL has that advantage.

Exactly.

> Though maybe we could offer up a JS-based
> form encryption scheme that could be stress-tested by the community
> here (if one doesn't already exist).

I believe there are JS implementations of standard security
"primitives" kicking around.
For instance, you can get sha1 in javascript from http://www.webtoolkit.info/javascript.html
and maybe someone can recommend some others. AES anyone? :-)

(A source of good random numbers might be trickier.)

> Just a small point..I thought I read in some book somewhere that
> Google had a way to direct users to their login pages even within
> other applications asides from the browser (so the user doesn't have
> to trust you with their google credentials).. can't remember the
> entire details..but I'll post if I find it again.

Please do! I wasn't aware of that, but it would be useful!

Although, how does it get data back to the desktop application? And
would this work, for example, on a mobile device?

> I will come back to study your whole post later, and no doubt I will
> have questions again on things I might apply in my own system :)
> Thanks again for your post!

No problem, glad to help!

-c

[Mike Koss]

I'm building my own session layer with encrypted tokens to
authenticate users. I am *not* using Public Key encryption (as SSL
does), so there is some vulnerability when a user first creates an
account - they have to transmit a shared secret to the server. But
once that is accomplished, all subsequent logins can use the shared
secret to authenticate user tokens to establish new sessions, w/o
exposing secret to anyone listening in on the connection.

Not as good as having a true SSL connection, but works fine for a low
level of security and basic account protection.

[Filip]

>
> I believe there are JS implementations of standard security
> "primitives" kicking around.

> For instance, you can get sha1 in javascript fromhttp://www.webtoolkit.info/javascript.html

> and maybe someone can recommend some others. AES anyone? :-)
>

Check out JavaScrypt at http://www.fourmilab.ch/javascrypt/
It claims to use AES, and has full Javascript code available for both
encoding and decoding messages.

Filip.

[Canis]

On Jun 26, 1:02 am, Filip <filip.verhae...@gmail.com> wrote:
> Check out JavaScrypt at http://www.fourmilab.ch/javascrypt/
> It claims to use AES, and has full Javascript code available for both
> encoding and decoding messages.
>
> Filip.

That looks pretty comprehensive -- thanks Filip

[Filip]

Not having SSL is a serious issue that needs to be addressed.

In my application concept, data is encrypted using a organisation-
specific password before uploading it to the Google data store (in the
browser or in the bulk loader, that doesn't matter for the
discussion). The Google data store does not have the key to decrypt
it, and the GAE application also does not contain the key. So the data
is stored securely, and is secure in transit too.

Assume the user is logged in and hence has access to the data. When
the user requests a page with this data on, the page is sent in
cleartext except that the data is returned as an encrypted string
(actually, from the server's point of view, it is just a nonsense
cleartext string - nothing special).

I intend to use Javascript in the browser to decrypt the values after
receiving them.

Off course, since everyone in the organisation needs to be able to
access this data, every user would need to know the organisation
decryption password and pass it to the browser for every page
retrieved. Far from ideal.

Therefore, I have been considering to require my users to install a
little app locally that creates a localhost at my custom port. This
app asks the users password once, and using that password it can
decrypt the organisation's password which was stored in its
configuration file.

Then the Javascript on the page that contains the data would call the
localhost with the string to be decrypted, and get the decrypted
string back (the organisation password itself is never given to the
user).

The main advantage is that it is secure despite not having SSL, and it
is even secure from prying eyes at the server side. No search warant
to Google could read this data.

But this approach has two obvious drawbacks:
* I need to force the user to install and start a local mini webserver
to see the values;
* This is a crossdomain call to the localhost, which might not be
allowed by security settings?

What do you think? Does this proposed approach make sense? Do you have
a better idea? Is it fatally flawed? Any input is welcome.

Filip.

On 26 jun, 02:02, Filip <filip.verhae...@gmail.com> wrote:
> > I believe there are JS implementations of standard security
> > "primitives" kicking around.
> > For instance, you can get sha1 in javascript fromhttp://www.webtoolkit.info/javascript.html
> > and maybe someone can recommend some others. AES anyone? :-)
>

> Check out JavaScrypt athttp://www.fourmilab.ch/javascrypt/

[Filip]

> But this approach has two obvious drawbacks:
> * I need to force the user to install and start a local mini webserver
> to see the values;
> * This is a crossdomain call to the localhost, which might not be
> allowed by security settings?
>

Hm, seems I could bypass the cross domain issue by using JSON:
http://borkweb.com/story/the-case-for-json-what-is-it-and-why-use-it#_json-and-cross-domai_1

That leaves just the annoyance of forcing a local security package
install on my users. In a business user setting, that's not
unreasonable.

Or am I not seeing some security flaws in my concept?
Filip.

[Mike Koss]

Secure protocols are notoriously hard to get right. I would be
hesitant to reveal a global encryption key to *everyone* in an
organization. Far better, would be to assign each user their own key,
which you could then expire. If you can distribute user-specific
passwords to each user, then you could authenticate them to AppEngine
w/o having to give them the global key. Then, you could decrypt your
data on appengine, and re-encrypt it with a user-specific key.

That way, you can revoke an individual's access w/o compromising all
the organizations data.

Here's an example. Suppose each user has an individual user name, U,
and secret password, P. By using a secure hash (like SHA1 - with both
Python and Javascript standard implementations), you can log in to
AppEngine like this:

AppEngine generates a unique (cleartext) session key, S, as a
"challenge".
User responds with S,H(S+H(U+P)). Your server now knows the user is
authentic (note that the server need only store H(U+P) for each user -
never their passwords in clear text). Server can then send an
encryption key, K, by sending I,K xor H(I+H(U+P)) (where I is an
initialization key - never re-used). Only the authentic user can
compute H(I+H(U+P)) and xor to recover K.

One vulnerability I've not seen discussed, is whether the Google
AppEngine upload tools use a secure connection. If not, your source
code could potentially be sniffed when you are deploying your web
server (including all your private keys for the server).

[Filip]

> Secure protocols are notoriously hard to get right.  

Wish I didn't need to do this, but here we are.

> I would be
> hesitant to reveal a global encryption key to *everyone* in an
> organization. Far better, would be to assign each user their own key,
> which you could then expire.

Absolutely. That is effectively what I am proposing. The user never
knows the global key, but uses his personal key to get access to a
decrypting service that does know the global key.

> If you can distribute user-specific
> passwords to each user, then you could authenticate them to AppEngine
> w/o having to give them the global key.  Then, you could decrypt your
> data on appengine, and re-encrypt it with a user-specific key.

However, in my approach, App Engine does not own the key at all. It
does not know the global key. The only thing it knows is the standard
login, and that is used to determine whether the user gets access.
Since App Engine doesn't know the global key, the only thing it can do
is return what it received.

>
> That way, you can revoke an individual's access w/o compromising all
> the organizations data.
>
> Here's an example.  Suppose each user has an individual user name, U,
> and secret password, P.  By using a secure hash (like SHA1 - with both
> Python and Javascript standard implementations), you can log in to
> AppEngine like this:
>
> AppEngine generates a unique (cleartext) session key, S, as a
> "challenge".
> User responds with S,H(S+H(U+P)).  Your server now knows the user is
> authentic (note that the server need only store H(U+P) for each user -
> never their passwords in clear text).  Server can then send an
> encryption key, K, by sending I,K xor H(I+H(U+P)) (where I is an
> initialization key - never re-used).  Only the authentic user can
> compute H(I+H(U+P)) and xor to recover K.

Hm. Interesting. Good way to authentice users. That may be relevant
when I consider using a different login method than Google's method.
Which is something I'm thinking about, since OpenId is not yet
supported.

It is however a different issue from the one I'm talking about.

To clarify, I'm thinking about encrypting the data before I send it,
and decrypting it after I have received it back. Google App Engine is
not doing any encryption/decryption. The nice thing about this is that
I can tell my customers that although their data is stored on Google,
even Google cannot read the data stored (let alone a hacker). Off
course, this hinges on the security of the client, and in particular
how well the organisation-wide key is encrypted and protected by
personal passwords.

>
> One vulnerability I've not seen discussed, is whether the Google
> AppEngine upload tools use a secure connection.  If not, your source
> code could potentially be sniffed when you are deploying your web
> server (including all your private keys for the server).

I believe that in my approach this vulnerability would not exist. But
I am looking for vulnerabilities, so correct me if I am wrong...

Filip.

[max7]

I am doubt if Google will or will not support SSL.
But I am sure that RFC 4366 is not required to do that.

Here is how current version of AppEngine works.

(Web Request) -> (Router) -> (Proxy) -> (FastCGI)

There is cloud of proxy and cloud of fastcgi servers.

In short you can have 1 IP to host all apps as router distributes
requests to proxy cloud and proxies send requests to FastCGI servers.
e.g. Apples iweb hosting uses 1 IP to host 24 thousand sites.
http://news.netcraft.com/archives/2008/03/26/march_2008_web_server_survey.html

So you can have 1 IP infront and proxy cloud inside.

And router will act as NAT and change External IP and port to Internal
IP and port.

e.g. each proxy may have 100 or 1000 certificates on different ports.

So google may have 1 external IP per client to support SSL.

If your site will have so big SSL traffic that router like Cisco CSS
or F5 BIG IP will not able to distribute it between hundreds of
proxies then you can have second external IP for DNS distribution.

> pointing your browser tohttps://appgallery.appspot.com/:

[Filip]

Hi,

> I am doubt if Google will or will not support SSL.

Let's face it.

Amazon has SSL abilities, but does not scale as well as Google yet.
But they have said they intend to make scaling easier, and I'm sure
they are actively developing on SimpleDB's capabilities.

Microsoft has SSL by default for their on demand data store (SSDS),
but they don't have a hosted app site yet. They have given lots of
hints they will announce just that at their next PDC event (October
27, 2008). SSDS works differently from BigTable, in some ways better,
in some ways not as good. But they are a competing offer and they
offer SSL today. A heck of a lot easier to tell customer's you are
uploading your data there.

Salesforce.com has SSL by default. Even though they may appeal to a
different developers audience, they are ultimately competing in the
domain.

Smaller vendors are not on my radar, as I don't believe they have a
future unless snapped up by one of the big guys, or when backed with
enormous cash to build to scale. Which is a chicken and egg situation.

Anyway, so either Google provides SSL in the future, or they will fade
away as a platform. This is the most important battle of the coming
years. And my guess is they will not fade away... This really isn't
something Google has a lot of options on.

However, the timeline is a different matter. WHEN will they have it?
My advice would be they'd best best beat Microsoft to the punch,
because a securely hosted .NET development platform is a tremendous
opposition for Google. You may or may not trust Microsoft, but their
wide ISV network is accustomed to working with .NET and trusting
Microsoft. I know, I've been in that circle for many years. Microsoft
is a very good and rewarding partner to work with. So I'd advocate
Google needs to do this sooner rather than later. But we all know
resources at Google App Engine are tight (hard to believe for an
effort of such strategic importance to the company, but apparently a
fact).

> But I am sure that RFC 4366 is not required to do that.

> [...]

> In short you can have 1 IP to host all apps as router distributes
> requests to proxy cloud and proxies send requests to FastCGI servers.

> e.g. Apples iweb hosting uses 1 IP to host 24 thousand sites.http://news.netcraft.com/archives/2008/03/26/march_2008_web_server_su...

>
> So you can have 1 IP infront and proxy cloud inside.

But without TLS SNI, 1 IP can translate only to 1 certificate, and
Google cannot provide an IP address for each application they host.
Clearly, it would be better for both Google and the application if the
certificate is application-specific, and not *.appspot.com.

> e.g. each proxy may have 100 or 1000 certificates on different ports.

I don't think using ports are an option either. My application uses
port 80 (of the secure platform default port like 443 for SSL). If the
platform provider cannot support that port, well nothing personal, but
then I'll use another platform. I'm not going to even try to convince
customers to change their corporate security in order to use my
application. That's a battle you cannot hope to win with big
customers.

Filip.

[max7]

You have not understood me.
Each SSL app will have 1 IP infront with standard port 443.

But router will distribute connections to proxy cloud.

Each proxy will have different port for different SSL.


https://www.myapp.com/ -> 222.222.222.222:443
https://www.anotherapp.com/ -> 222.222.222.223:443

When visitor connects to

222.222.222.222:443 router deiced send his request to one of proxy
webserver

10.0.0.1:10222
10.0.0.2:10222
10.0.0.3:10222
10.0.0.4:10222
10.0.0.5:10222

When someone connects to second app

222.222.222.223:443

10.0.0.1:10223
10.0.0.2:10223
10.0.0.3:10223
10.0.0.4:10223
10.0.0.5:10223

10.0.0.1 - 10.0.0.5 - are proxy webservers that listen on different
ports

port 10222 is www.myapp.com
port 10223 is www.anotherapp.com

Each proxy webserver may have 1000 SSL ports

proxy webserver connects to app contains hosting python scripts.


Google may afford 1 IP per app with SSL as every hosting provider is
able to offer IP is you have SSL cert.

[Filip]

I understand. Good idea in normal circumstances.

However, when Google trew the doors open on registration, there were
about 140.000 registered developers, which theoretically each can
create 3 applications. That's a theoretical 420.000 apps right from
the start. That's a lot of IP addresses, and a lot of proxy servers.

Sure, only a small fraction of these registered users will actually
develop real apps, but some secure pages is likely on the mind of many
real apps. And I guess the real momentum for these new platforms has
yet to come. Already some professors are using GAE as a teaching
platform. Just image the volume of little test apps using SSL for a
few pages.

So this could present a scaling issue.

Filip.

On 26 jun, 14:40, max7 <max.seven....@gmail.com> wrote:
> You have not understood me.
> Each SSL app will have 1 IP infront with standard port 443.
>
> But router will distribute connections to proxy cloud.
>
> Each proxy will have different port for different SSL.
>

> https://www.myapp.com/-> 222.222.222.222:443https://www.anotherapp.com/-> 222.222.222.223:443

[max7]

I think it is obvious that SSL would be a paid and optional feature.
It requires more CPU cycles or additional SSL accelerators to process
SSL requests.
SSL traffic will cost more.

+ Customers will have to buy SSL cert.

It does not mean that if google will support SSL then it will give
millions IPs to every app hosted for free.

[Mike Koss]

I agree with you. If you only store encrypted data on GAE, and only
decrypt on the client, then there is "in theory" no way for anyone in
the public to retrieve your private information. GAE is acting as an
untrusted (insecure) service.

You are effectively stating that you will publicly release the
contents of all the data you'll be storing on AppEngine. So you'll
want to ensure that it is completely stripped of private information.

This can also be tricky as you will typically want to use the data
store to perform queries on your data. Any attempt to store data in a
way that could enable you to query for particular values and return
them in sorted order, for example, is effectively leaving a back-door
to inferring the original un-ecrypted information. I would think the
only operation you could safely perform, is to look up a block of
data, given a key.

Let me give an example of what could go wrong using a system designed
as you describe. The safest mode I can think of would be something
like this. Suppose I am storing user names, U, and social security
numbers (S). My only application is to request the social security
number of a given user from the server. I have a global encryption
algorithm G, that only is known and used on the client machines, and
never on the server.

If you store records in AppEngine as:

def MyData(db.Model):
gu = dbStringProperty() # G(U) - encrypted user name
gs = db.StringProperty() # G(S) - encrypted ssn

You will be able to query the database for single ssn's at a time. As
long as G is a very good encryption algorithm there is not much to
recover from the stored dataset.

But, suppose you choose a subtly different scheme:

def MyData(db.Model):
gfirst = db.StringProperty() # G(First_Name)
glast = db.StringProperty() # G(Last_Name)
gs = db.StringProperty() # G(S)

If you have a large enough data set, an attacker can observe the
frequency patterns of English first and last names in your data. He
may be able to determine with high confidence, which records are
"Smith" and which are "Mike". Having guessed these two, he can then
find the record(s) for "Mike Smith".

Any data that does not come from a large enough set of original
values, will reveal patterns in the encrypted forms that could lead to
someone recovering the relationships from your data set. It would
generally not be safe to individually store things such as:

- Salary
- Sex
- Age
- City, State, Zip
- Rank or employment level
- Date of Birth

Any data that you need to use as Key information will be vulnerable to
this kind of analysis. The good news is that if you are only
retrieving these values, you can "salt" your data with additional
random information before encrypting it. This can be stripped away
after decryption, and will render your data set truly random looking.

Also, without server-based encryption, you will also not be able to
build a read-write system, as you will not be able to authenticate
your users as being genuine.

In summary, I think the only way to build a safe system as you
describe is if it is read-only, and only performs single record
"get's" from a sufficiently large key set, into a sufficiently large
domain.

[Filip]

First off, thanks for the long and detailed response. Really good
arguments.

> You are effectively stating that you will publicly release the
> contents of all the data you'll be storing on AppEngine.  So you'll
> want to ensure that it is completely stripped of private information.

Well, with a twist. I would still use Google accounts to authenticate
users. So you would not be able to retrieve large data sets for
analysis. Well, assuming Google isn't the one doing the decrypting,
off course.

However, the uploading of data still allows for massive sniffing. Ah,
the joys of default SSL. I've actually considered making an SSL
intermediate stop on an external server. I believe GAE can use HTTPS
to request data from external services?

> Any data that does not come from a large enough set of original
> values, will reveal patterns in the encrypted forms that could lead to
> someone recovering the relationships from your data set.  It would
> generally not be safe to individually store things such as:
>
> - Salary
> - Sex
> - Age
> - City, State, Zip
> - Rank or employment level
> - Date of Birth

Very true, plus any freetext as it may contain clues on the identity
of the person.
The problem is that attributes like Age, Sex and City/State/Zip need
to be queryable.

> Any data that you need to use as Key information will be vulnerable to
> this kind of analysis.  The good news is that if you are only
> retrieving these values, you can "salt" your data with additional
> random information before encrypting it.  This can be stripped away
> after decryption, and will render your data set truly random looking.

Wouldn't salt interfere with the ability to look a record up? Suppose
I wanted to find all information in the database about Filip
Verhaeghe. I was thinking of encrypting that name and looking up the
encrypted equivalent.

Or would you propose a prefixed system wide client side salt thingy.
To give a simple example, every third character is switched with every
7th character. Or perhaps the salt itself should be an excrypted field
different for every record?

> Also, without server-based encryption, you will also not be able to
> build a read-write system, as you will not be able to authenticate
> your users as being genuine.

OK, I'd still use Google account for identification. I'm really
focussing transport and storage security.

Filip.

[Mike Koss]

> Wouldn't salt interfere with the ability to look a record up? Suppose
> I wanted to find all information in the database about Filip
> Verhaeghe. I was thinking of encrypting that name and looking up the
> encrypted equivalent.

You only need apply salt to any property that might be repeated across
a large record set. Fixed salting (the same across all data), really
does nothing additional for you as you are already assuming G(data) is
strong. And you can't apply random salt to anything you need as a key
for a lookup (as your example).

As I said, if your just doing a GET on a single key, e.g.,
G(user_name), that seems pretty safe. You run into problems on
queries like:

SELECT * FROM data WHERE g_admission_date = G(todays_date)

even worse:

SELECT * FROM data WHERE G_salary > G(50000)

The first requires a one-to-one equivalence between date data and your
stored data, making the values subject to frequency analysis and
partial information discovery.

The latter query is NOT POSSIBLE unless G is weakened to the point
that it preserves the sort order of your data (which renders G
practically useless as an encryption algorithm).

Any random salting eliminates the ability to use those values as
predicates in queries. A system wide salt doesn't improve anything if
it's the same procedure across all records. If all your requests are
looking up data for a particular user, you could, however, apply salt
that is user-specific. So, for example, if you had lots of
transaction data for each user, your "Transaction_Date" field could be
salted by the user name. This would at least give an attacker a much
smaller set of data to look for frequency patterns (only one user's
data set at a time). But you'd be able to do equality queries against
it.

I guess you'll have to upload the email addresses of all your users to
use with Google's User authentication. One other option for
authentication would be to have users prove they know the secret
encryption function, G, by logging in with user_name,G(user_name).

I think your system is basically workable if you're careful. But your
biggest vulnerability is that one global shared key, G. A "secret"
shared between 3 or more people is generally not able to remain secret
for long.

P.S.

One thing Google could do as an additional service for AppEngine,
would be to provide a shared secret for each logged in Google User.
This would give you enough info to build your own security layer using
the shared secret. As it is, the only thing you learn about a user is
their email address, which is hardly secret enough to use as the basis
for building secure key information. It would be really cool if
Google would give us SHA1(user-name|password). This would allow us to
build client side keys from user-supplied information that would match
server keys and could be used for authentication and encryption.

[Ale]

On Jun 26, 1:02 am, Filip <filip.verhae...@gmail.com> wrote:

> > I believe there are JS implementations of standard security
> > "primitives" kicking around.
> > For instance, you can get sha1 in javascript fromhttp://www.webtoolkit.info/javascript.html
> > and maybe someone can recommend some others. AES anyone? :-)
>

> Check out JavaScrypt athttp://www.fourmilab.ch/javascrypt/

> It claims to use AES, and has full Javascript code available for both
> encoding and decoding messages.
>
> Filip.

Clipperz was ported to GAE.
http://groups.google.com/group/google-appengine/browse_thread/thread/59b53f7188459d2/3396c5399e714032
http://www.clipperz.com/open_source/clipperz_community_edition

Alejo

[Filip]

> Clipperz was ported to GAE.http://groups.google.com/group/google-appengine/browse_thread/thread/...http://www.clipperz.com/open_source/clipperz_community_edition
>
> Alejo

Thanks, that look interesting. How is the transport secured?

Filip

[max7]

Is it possible to compile java cryptographic libraries into javascript
using GWT?

If yes then probably you can get any algorithm that way as most of
them are already implemented in java.
I doubt that it will work fast enough anyway.

The most important is open key cryptography.

1. It is will work very slow.
2. How would it get root certificates to validate SSL handshake?

If you will include these certificates as part of JavaScript library
then abuser may modify certs when you open page.

-------

I think the only secure thing is to send md5 instead of password.

var hash = md5(sessionCookie + login + password);

It would be possible to verify hash on server side and that hash won't
work for next session.

It is not secure as it would be possible to brute force password.

The only secure way to do things is open key cryptography as we can
define security level in the beginning.

----------

But open key cryptography

1. Is very slow.
2. There is no way for JavaScript to obtain root certificates to
validate handshake.

You can't include root certificates in JS library as some may modify
the page when you will open it with fake certificates.

If you will include these certificates as part of JavaScript library
then abuser may modify certs when you open page.

On Jun 27, 2:37 pm, Ale <joeplat...@googlemail.com> wrote:
> On Jun 26, 1:02 am, Filip <filip.verhae...@gmail.com> wrote:
>
> > > I believe there are JS implementations of standard security
> > > "primitives" kicking around.
> > > For instance, you can get sha1 in javascript fromhttp://www.webtoolkit.info/javascript.html
> > > and maybe someone can recommend some others. AES anyone? :-)
>
> > Check out JavaScrypt athttp://www.fourmilab.ch/javascrypt/
> > It claims to use AES, and has full Javascript code available for both
> > encoding and decoding messages.
>
> > Filip.
>

> Clipperz was ported to GAE.http://groups.google.com/group/google-appengine/browse_thread/thread/...http://www.clipperz.com/open_source/clipperz_community_edition
>
> Alejo

[giulio...@gmail.com]

Hello Filip,

On Jun 27, 5:12 am, Filip <filip.verhae...@gmail.com> wrote:
> > Clipperz was ported to GAE.http://groups.google.com/group/google-appengine/browse_thread/thread/...
>

> Thanks, that look interesting. How is the transport secured?

at the moment the AppEngine version of Clipperz is more a proof of
concept than a real application.

Personally, I have never even tried to run the application on a real
Google server; I have only developed and tested it on the SDK because
when I was working on it I hadn't an AppEngine account yet. And when I
got the AppEngine account I was already focusing on other tasks.

Anyway, the data the Clipperz client sends to the server are already
encrypted; the application level communication protocol is not
"secure" (as it does not detect replay-attacks, changed message
payloads, etc...) but the worst that could happen, even with an
unsecured communication channel is that some data are corrupted (that
is definitely not good), but nothing is ever leaked.

It would be probably possible to improve the strength of the
application level communication protocol to the point where SSL would
not be required anymore, but we did not take that path as telling
people they can safely store their password online is very hard, but
convincing them that it is safe even using an SSL connection would
have been really to much trouble, PR wise.

Hope this helps answering your doubts.

Best regards,

Giulio Cesare