1

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
Community
  • 1
  • 1
hectorg87
  • 753
  • 1
  • 7
  • 24
  • Can you provide a link to a reliable article that suggests to call hashing 1000 times for better security? – Igor Artamonov Jul 17 '12 at 13:47
  • 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 Jul 17 '12 at 13:50
  • But this question also have answer with more votes (31 at this moment). Why not this answer? – Igor Artamonov Jul 17 '12 at 14:01
  • @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 Jul 17 '12 at 14:04
  • @IgorArtamonov I edited my question to make clearer what I'm asking – hectorg87 Jul 17 '12 at 14:07
  • I fully understand that slower is better. But I don't uderstand why 'call fast hash thousands times' is better than 'call slow hash few times' – Igor Artamonov Jul 17 '12 at 16:27
  • Third answer, the one with 9 votes up: http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords OWASP recommendation and even the code they give for hashing + salting: https://www.owasp.org/index.php/Hashing_Java#Hardening_against_the_attacker.27s_attack Another link on the multiple hashing iterations: http://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once Apple uses thousands of iterations: http://blog.crackpassword.com/2010/12/cracking-blackberry-backups-is-now-slower-but-still-possible-thx-to-gpu-acceleration/ – hectorg87 Jul 17 '12 at 16:28
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/14006/discussion-between-hectorg87-and-igor-artamonov) – hectorg87 Jul 17 '12 at 16:30

3 Answers3

1

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.

Marcus Adams
  • 53,009
  • 9
  • 91
  • 143
  • And what is the free quota of instance hours? I expect to have my site running 24/7, however I don't expect too many users so probably one instance will be enough. And does really GAE doesn't count (or have a quota on) CPU time anymore? – hectorg87 Jul 17 '12 at 13:27
  • @hectorg87, The free quota of hours, in your case since it's going to run 24/7, you can imagine as a discount. You get that many free hours before they start charging you. I use Amazon cloud services, and it's the same way. If the server is busy, I get throttled to the CPU level I'm paying for. Processes will take longer, but it won't cost more. – Marcus Adams Jul 17 '12 at 13:31
  • I'm sorry but now I'm even more confused. What do you mean by "a discount". From my understanding, GAE does not charge the same way as Amazon, the Free Quota resets daily and it will run free "forever" as long as I stay below that Quota. Isn't that correct? – hectorg87 Jul 17 '12 at 13:39
  • @hectorg87, Hmm, sorry, if it's different from Amazon, then I don't know. Perhaps someone else can answer about the quota. Hopefully, I at least explained instance hours. Amazon's charges stack. There's a hour quota and a bandwidth quota, etc. – Marcus Adams Jul 17 '12 at 13:53
  • Thanks @Marcus, I'll wait for a GAE specific answer on Instance Hours quota then. – hectorg87 Jul 17 '12 at 13:59
1

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.

Moishe Lettvin
  • 8,462
  • 1
  • 26
  • 40
  • Thanks! You said something I didn't think about. There is only one "Processing Thread" per instance, right? So if I limit my GAE account to use only one instance to make sure I don't get over the quota, I have the risk of users waiting a long time because the only instance is busy processing the "big computation"? You are right about this being calculated only on initial sign-in rather than for every request – hectorg87 Jul 17 '12 at 15:59
  • Yes, if you limit to only one instance, you do run the risk of having users wait a long time. I believe there is only one "processing thread" per instance, but I asked this question to clarify: http://stackoverflow.com/questions/11525717/when-does-the-app-engine-scheduler-use-a-new-thread-vs-a-new-instance – Moishe Lettvin Jul 17 '12 at 16:06
  • Something to consider: you could write an App Engine app whose job is to do the computationally expensive part. Then make your "primary" app do an urlfetch to that app, so you could have multiple threads in your main app waiting on the hasher app, and individually tune your instance hours. This is effectively the same as "outsourcing" the hashing to an OpenID provider. – Moishe Lettvin Jul 17 '12 at 16:09
  • Thanks @Moishe, this settles it. I'll check the answers on the other question. – hectorg87 Jul 17 '12 at 16:21
0

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

stevep
  • 959
  • 5
  • 8
  • Hi @stevep. Actually, I'm doing what they recommend which is making the hashing process slow by key stretching. That's why I was worried on my Instance Hours and CPU-time in Google App Engine. Thanks for the links – hectorg87 Jul 18 '12 at 19:41