Hashing Password in Google App Engine and Instance Hours Quota

1
votes

I've been reading a lot about password storing, hashing, salting, "peppering", MAC, etc because I'm about to make a new website and security it's really important to me, however there are some reasons why I'm considering not using Google Authentication (or Facebook, OpenID or any other) which are not relevant right now, but it brings me to this point.

I'm new to Google App Engine, this is going to be my first project on it, and I'm a little confused about the "Instance Hours" and how it no longer has "CPU time" but the aforementioned quota. Even worst, I haven't been able to understand what is the Instance Hours Free Quota.

Here's why I'm worried about the quotas and what does that has anything to do with my security concerns: One recommendation I've read everywhere is to make multiple iterations and hash the password several times, because that would make and attacker spend much much much more time (I don't have numbers, but they are everywhere on https://security.stackexchange.com/).

Multiple iterations have direct impact on CPU time, and if GAE had a CPU time quota I think making 1000 iterations every time a user logs in could be a problem, however if what they count is Instance Hours from the moment the request is done to up to fifteen minutes later and as read on GAE quota docs is:

In general, instance usage is billed on an hourly basis based on the instance's uptime. Billing begins when the instance starts and ends fifteen minutes after the instance shuts down. You will be billed only for idle instances up to the number of maximum idle instances set in the Performance Settings tab of the Admin Console. Runtime overhead is counted against the instance memory.

then it means that if my users log in (hash 1000 times), then they continue to use the site, the Instance Hours will continue to sum until all of them leave the page + 15 minutes? If this is true, then making it iterate 1000 times wouldn't have a significant impact on my quota, other than the "extra" time it takes for the user to log in, but I'm aware of that and it's a price I'm willing to pay.

The number of iterations I'll make will be the ones that make the time to log in acceptable and imperceptible to the user, so don't worry about this.

My questions are:

  1. Will making MANY iterations have a direct impact on the Instance Hours, or my assumptions about how the Instance Hours are summed are correct?
  2. Is there a CPU time quota on Google App Engine I'm missing somehow? Does it have a Free Quota?
  3. What is the Instance Hours Free Quota?

Answers:

  1. Look Moishe accepted answer and the other question he asked (which has not been answered but has usefull comments) When does the App Engine scheduler use a new thread vs. a new instance?
  2. According to Google there is no CPU time quota: http://googleappengine.blogspot.com.es/2009/02/skys-almost-limit-high-cpu-is-no-more.html
  3. Found an answer to question number 3 here: Google App Engine Frontend Instance Hours Limit Reached
3
javasecuritygoogle-app-enginepasswordshash
Can you provide a link to a reliable article that suggests to call hashing 1000 times for better security? - Igor Artamonov
It's not about the security of the password, but about the time it takes to crack a password that has been hashed many times. I will provide the links, just give me a couple minutes - hectorg87
But this question also have answer with more votes (31 at this moment). Why not this answer? - Igor Artamonov
@IgorArtamonov because my question is about Google App Engine and the Instance Hours free quota, I just wanted to give context to my question. I'm not asking whether to hash it 1000 times or one, but what is the Free Quota of GAE on Instance Hours and what are "Instance Hours". Marcus Adams already answered me what are Instance hours, I'm waiting for an answer on the free quota - hectorg87
@IgorArtamonov I edited my question to make clearer what I'm asking - hectorg87

3 Answers

1
votes

Instance hours are for long as the server is running, answering requests, etc. If your server isn't running, it can't wake up on a request or anything.

Imagine instance hours as having the computer on. You are billed when it's on, and not when it's off.

You could have multiple instances, so let's say you have two instances, you're burning twice as many instance hours.

Your password hashing won't affect this because it will only incur instance hours when the instance is on, and when its off, it won't be incurring any instance hours, but it won't be hashing either.

1
votes

If it takes a long time to process a request, because eg. you're doing something very computationally intensive, and you don't want other users to wait a long time, the App Engine scheduler may spin up another instance of your application to serve incoming requests.

Imagine that computing the hash for a password takes 1 minute and during that minute your application gets a request from another user. That user could wait for a minute to get a response to their request, or the App Engine scheduler could spin up another instance to service that request and get a response back much sooner. You can tune whether or not another instance will come up using the Performance sliders on your Application Settings page in the admin console.

Basically the question you need to ask about instance hours is: is it likely you'll get overlapping requests (ie. a new request coming in before the current request is complete). If this happens not-infrequently, and you want snappy response for your users, you'll need to budget more instance hours.

I suspect that the big computation you'll need to do will be infrequent -- only on initial sign-in to generate a cookie, say, rather than for every request.

To explicitly answer your question #1, making many iterations will only have an effect on your instance hours if it causes overlapping requests. If you only get one request every 30 seconds, you could spend 30 seconds serving each request (including calculating each hash, and doing other operations) and not exceed your free instance-hours quota. Conversely if you get 10 requests per second and spend any more than 100ms serving the request, then you'll start to exceed your instance hours fairly quickly.

0
votes

There are multiple sources covering passwords. You evidently have read some that encourage multi-pass hashing. Consider the first link below before finalizing this decision. Excerpt from this page: "It's easy to get carried away and try to combine different hash functions, hoping that the result will be more secure. In practice, though, there is no benefit to doing it. All it does is create interoperability problems, and can sometimes even make the hashes less secure."

Two valuable links to consider( first has quote above, second is good "how to" source):

http://crackstation.net/hashing-security.htm

http://throwingfire.com/storing-passwords-securely/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+throwingfire+%28Throwing+Fire%29#notpasswordhashes