How to Safely Store Your Users' Passwords in 2016 - <AUTHOR> https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016 <comment><USER2> I called my bank the other day and they asked over the phone for my password. This isn't a bank I often use, I only currently have a loan through them so I've never used the login on the website. I said I don't remember setting a password. They gave me a hint about the characters in the password and I was able to remember the password based on their hint. I verbally said the password character by character and they confirmed it. This is an example of how to not handle passwords in 2016.

<comment><USER3> Same thing happened to me, my local credit union emailed me my password. They ensured me that they use "bank-level encryption". Of course I didn't get into the difference between one- and two-way encryption with the teller, or that email isn't secure.

We live in an age where this should be unacceptable. Why aren't there financial security laws yet?

<comment><USER4> It's so infuriating because I've worked at companies doing digital commerce before, and PCI compliance and certification is quite onerous. But at the end of the day credit card numbers still aren't as sensitive as bank logins, yet there are no security standards on bank logins! It's crazy.

<comment><USER5> PCI compliance is pretty interesting. It's been many years since I worked in an e-commerce shop but I seem to remember that it even described physical security layers i.e., dictating the placement of door hinges to server rooms.

<comment><USER6> Goes to show that when money is at stake for the stakeholders then things get done.

I don't think banks actually care about individual user login security too much. Credit Cards reallllly suffer from security breaches though

<comment><USER7> > I don't think banks actually care about individual user login security too > much. Credit Cards reallllly suffer from security breaches though

But the only reason that banks care so much about credit-card security breaches is that the law forces them to do so. If the law didn't make credit card fraud the bank's responsibility, then they'd be just as lackluster about preventing it as they currently are about securing login credentials.

<comment><USER8> I don't know if that's true. Say we lived in a world where those regulations didn't exist and the fraud risk was on par with what it is today. If _one_ bank introduced their own fraud protection program, wouldn't they basically capture 90% of the market overnight?

<comment><USER7> This is a good argument, but I'm not sure that I buy this. There are plenty of industries (I think of the cable and cell-phone industries, but I'm sure there are others) where it's just a given that the service will be crappy, even though one company that started to respect its customers could seemingly corner the market. (I'm not sure what are the results of T-Mobile's exercises in respecting its customers. Their unfortunate net-neutrality stance with Binge On means that it's not an unalloyed win to go with them.)

<comment><USER8> I get what you're saying, but credit cards are unique: the advantage credit card companies have over those other industries is that there is essentially no lock-in, and your old cards continue to work while you're in the process of switching eg your autopays over. It's a very switch-friendly industry.

Remember when you couldn't take your cell phone number with you and so pretty much nobody switched carriers? It was a massive pain. Now it's easier than ever to switch, except most people are locked into multi-year contracts. Switching friction = high, but not impossible. As you said, TMO is trying to compete here.

Cable has monopolies on towns, so there's 0 incentive. People couldn't switch even if they wanted to. I suppose there's satellite, but you'll still be paying the cable company for internet -- they get their pound of flesh no matter what. Switching friction = impossible.

<comment><USER7> These are good points. My remark was off the cuff; it's clear that you've thought (or at least are thinking) about it much more deeply.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Bad idea to use bcrypt.hashSync in Node.js. I hate that so many tutorials use that one instead of the correct bcrypt.hash with a callback. This is Node.js for that 200 ms where you are hashing that password nothing else runs, no requests, everything stops. Here is the correct way to use bcrypt in Node.js:

bcrypt.genSalt(10, function(err, salt) {

      if (err) return; //handle error

      bcrypt.hash(clearPassword, salt, function(err, hash) {

        if (err) return; //handle error

        // Store hash in your password DB.

      });

});

<comment><USER10> Note that bcrypt.hash just calls bcrypt.hashSync anyways[0]. So there it's still going to stall exactly the same amount.

edit: Looks like it depends on which version you use.

'npm install bcrypt'[1] gives a version which supports true async usage (via V8 async callbacks in native code)

'npm install bcrypt-nodejs'[2] gives a pure JS version which I linked to. Which is the top search result for 'nodejs bcrypt'

[0] - [https://github.com/shaneGirish/bcrypt- nodejs/blob/master/bCr...](https://github.com/shaneGirish/bcrypt- nodejs/blob/master/bCrypt.js#L630)

[1] - [https://www.npmjs.com/package/bcrypt](https://www.npmjs.com/package/bcrypt)

[2] - [https://www.npmjs.com/package/bcrypt- node](https://www.npmjs.com/package/bcrypt-node)

[3] - [https://www.google.com/search?q=nodejs+bcrypt](https://www.google.com/search?q=nodejs+bcrypt)

<comment><USER11> BUT NODE.JS IS NON BLOCKING?!?@?!?!?!

Kidding.

<comment><USER12> It's IO-bound. I guess they could make a version that yields and resumes several times though!

</comment></comment></comment></comment><comment><USER13> By not storing them [https://medium.com/the-story/signing-in-to-medium-by- email-a...](https://medium.com/the-story/signing-in-to-medium-by-email- aacc21134fcd#.fkttu9kdh)

<comment><USER14> So there's no password option? That's horrible, means you can't use it with incognito mode (because you'd have to receive an email each time)

<comment><USER15> You can use the link in incognito. Why wouldn't you?

<comment><USER14> Because every time you open the site you'd have to receive an email. vs just letting 1password, browser, etc enter the password.

</comment></comment></comment></comment><comment><USER16> Serious question: What about using a Public/Private key encryption to store the password?

\- Private key is stored in a secure place. Offline for all i care; printed on a piece of paper; memorized and swallowed.

\- When user creates the account - password is padded with salt, then a public key is used to encrypt it. The resulting encrypted form is stored, along with the salt.

\- When user attempts to authenticate - the password that is provided is padded with the stored salt, encrypted with the public key and compared to the stored password.

Private key is never used when comparing passwords. Never available to the system doing authentication, etc.

The only purpose of using a reversible encryption - is to be able to switch to a different authentication provider completely transparently to the user.

I've implemented this functionality considering that we may need to switch over to active directory (or some other directory) in place of storing passwords in the database - but never used it, fearful that i would be committing some cardinal crime against proper security practices

Thoughts?

<comment><USER17> This only works for deterministic encryption like "textbook RSA", not for any semantically secure encryption, which would produce different ciphertext each time you run it.

I would worry about trying to dual-purpose the encryption like this. If you feel like you must have a way to get the plaintext password back, which BTW you really really do NOT want that liability, but anyway, the safer choice would be to use a semantically secure encryption of the password, and then ALSO hash the password using the current best practices. Use the hash for now to authenticate users, keep the ciphertext if you must, but you'll probably regret it.

<comment><USER16> Thanks for you reply. It is indeed RSA that I used (from .NET framework).

There's no argument from me regarding undesirability of keeping the passwords. But we also have a different concern - we don't want to be in the business of authentication _at all_ \- our goal is to have a third party service or appliance performing authentication and forwarding us already authenticated sessions with the user name as a header, for instance. Our desired end-state - is when we do not have any knowledge of or access to credentials used by the end-user.

To enable us to make this transition possible - for the time being we store the passwords, since as i explained in another reply, we must make this transition transparent to the users and we have legitimate users that login once a year (think credit report, just an example, not our business), so we can't intercept the credentials within a reasonable time period.

What i try to get out of the replies - is whether there's nothing immediately broken about using asymmetric encryption that endangers us aside from the understandable but not immediate concern about liability.

P.S: Earlier i mentioned "intercepting credentials" in our code - and wanted to highlight that the ease of doing that is precisely the reason why we really want to separate ourselves from handling credentials in any form.

</comment></comment></comment><comment><USER18> If you're using node.js and you use these hashing methods, your entire server is going to pause for 0.5 seconds on a login because it runs on a single thread. Goodbye to all of your server performance.

You can create a worker system, or use a child process to solve this problem, but most of these articles never mention it

<comment><USER19> I think this says more about node.js than it does about the proper way to secure a password.

<comment><USER20> Wasn't Node's big draw early on (aside from the fact that it's JavaScript) the fact that everything is supposed to be asynchronous? I'm actually surprised this is a problem.

<comment><USER21> asynchronous doesn't magically make CPU-intensive tasks faster.

<comment><USER22> It does mean other tasks (e.g. serving pages to visitors) can still be run at the same time as the CPU-intensive task though, like most languages do when it comes to hashing passwords and logging people in

</comment></comment></comment></comment></comment><comment><USER23> > base64_encode(hash('sha384', $password, true))

> ...

> The above construction may invite theoretical concerns about entropy > reduction (i.e. 72 characters of raw binary without any NUL bytes comes out > to about 573 bits of possible entropy, but a SHA-384 hash outputs are > clearly limited to 384 bits).

Given BCrypt hashes are a mere 184 bits, I don't see how this is a meaningful concern even in principle. If you're brute-forcing search spaces this big you're no longer looking to recover a password, but find a collision.

<comment><USER24> > Given BCrypt hashes are a mere 184 bits, I don't see how this is a > meaningful concern even in principle.

This was added in response to a point that a couple people (or perhaps a convincing sockpuppeteer) raised and tried to use to decry the entire article. You're lucky to get 60 bits of information entropy in any given user's password, as is. The "theoretical weakening" here isn't a practical concern: "2^192 security" is still boring crypto.

</comment></comment><comment><USER25> I had no idea that PBKDF2 had fallen so much in recent years. I still remember the 1Password team extolling its virtues five years ago:

[https://blog.agilebits.com/2011/05/05/defending-against- crac...](https://blog.agilebits.com/2011/05/05/defending-against-crackers- peanut-butter-keeps-dogs-friendly-too/)

<comment><USER24> Correction: Scrypt actually uses PBKDF2 internally. (Previously said "scrypt is based on PBKDF2" but that's a loaded statment.)

PBKDF2 is an improvement over PBKDF1 (and other naive iterated hash constructions), but attacks got better and better defenses are called for.

<comment><USER26> _Scrypt is based on PBKDF2._

No, it really isn't.

<comment><USER24> I could have sworn it used PBKDF2-SHA256 and Salsa20/8 internally, which is what I meant by "based on".

<comment><USER26> It also uses xor internally, but I wouldn't say that scrypt is based on xor. scrypt does not use PBKDF2 for any PBKDF properties; it's just a convenient arbitrary-length-output hash function. I would have used a sponge if they had been widely available when I created scrypt.

<comment><USER24> Okay, thanks for the clarification.

</comment></comment></comment></comment></comment></comment><comment><USER27> It would be great if, in 2020, or sooner, but probably later, the answer is "don't use passwords any more. They are deprecated components of society."

<comment><USER28> Can you expand on this idea? What type of authentication method would replace it? (One that can't be directly linked to the person obviously).

<comment><USER29> I'm optimistic for the use of physical tokens instead of passwords. In my work environment, a lot of authentication is based on physical token possession plus a password just as a guard against lost devices (password validated by the token, not by the service).

These kinds of systems aren't technically very complex but there hasn't been a lot of traction for them outside of corporate environments. The result is that they tend to be hyper-expensive, unfortunately. Standards like FIDO and the Yubikey are good first steps at pushing this into the consumer space, although they don't offer on-device PIN validation yet.

<comment><USER30> I would love a replacement for passwords, but i dont think hardware based solutions are practical enough yet. It is a Gadget more i need to take with me, and even more make sure that it connects with any device i have.

The worst part for me would be loosing that thing, in the end i would need alternative login methods anyway to be sure i dont lock myself out.

Classic Authy on a Smartwatch would be the simplest method i could live with that comes to my mind.

<comment><USER31> Its not one more Gadget that you have to carry around. New Lenovo Laptops and Samsung Phones already have UAF enabled Fingerprint Sensors that could be used for all your Web Authentification needs. The Yubikey is either the size of a USB slot or the size of a key on your keychain, so even your second factor is pretty minimal in size.

Alternative Login is always a problem, their is always a tradeoff between security and useability. You could easly print out some backup access codes. You can continue to use your E-Mail as a anker, you get an E-Mail and then your allowed to register a new token. That leaves the question of how does your E-Mail provider secure its login? I think Google is a good example of the options that are possible.

</comment></comment></comment></comment></comment><comment><USER32> Disappointed that the first solution isn't: Let somebody else do it.

I know this doesn't apply to banking, etc but 99% of the websites that "require" me to create an account and log in don't need to store primary credentials for me. Please pick a secure implementation of oAuth2 and let people store their credentials wherever the hell they want to.

I'm bored of getting hits from "Have I been pwned?"

<comment><USER24> This requires your users to trust whichever OAuth providers you decide to integrate with. Sometimes, the set of "trusted OAuth providers" for your users is {}. What then?

> 99% of the websites that "require" me to create an account and log in don't > need to store primary credentials for me

Why are you giving them valuable credentials? Give them a throw-away password (password managers are great for this).

<comment><USER32> You don't integrate with _a_ provider. You implement the protocol and let your users supply a URL. Layering on popular alternatives (Facebook, Google, etc) help, but use the Stack Exchange model. Let users do what they want to do.

That way users can be their own oAuth providers if they want.

<comment><USER24> My question was: "What if your users don't trust any of the existing providers on Earth?"

It's hard to make a blanked recommendation like that, even for "only 99%" of websites. Neither you, nor the person building the website, has any insight into who the website's users trust.

Offer OAuth2 as an alternative to passwords: Great move.

Only offer OAuth2 and don't let people create an account: Questionable.

<comment><USER32> I did answer.

They can host their own.

I don't understand why they would trust <crappy forum owner> over a dedicated authentication storage place but that's their choice. And yes, there is also every possibility to offer direct credentials, per the Stack Exchange model (they host their own oAuth server and allow simple registrations).

<comment><USER24> > I don't understand why they would trust <crappy forum owner> over a > dedicated authentication storage place but that's their choice.

What if <crappy forum owner> happens to be a security engineer, and <crappy forum> happens to be Silk Road 13?

The trust decisions people make are situational and nuanced. OAuth is great if that's where people invest their trust. Otherwise, you're outsourcing it for the user to a company they might fear.

<comment><USER32> Again. The _user_ picks who they authenticate with. You (the site owner) get no say in the matter. You aren't outsourcing it to any one company.

<comment><USER24> No, you're saying "which of this limited set of companies are you going to authenticate with" instead. If you don't want to be guilty of taking users' agency away from their own trust decisions, you need to do one of two things:

1\. Let every website on the Internet potentially be an OAuth provider.

2\. Make OAuth optional.

If you follow option #2, then this article is still relevant because you need to handle passwords securely.

<comment><USER32> Your first paragraph is like saying using email is forcing somebody to use one of a "limited set of companies". It's nonsense. Again, if they don't like what's on offer they can host their own, just like email!. They can hire a company like yours to host their credentials with as many layers of security as they want. The user has ultimate choice.

Secondly, every website on the Internet _is_ potentially an OAuth provider.

Not to mention that I have —on multiple occasions here— suggested that websites that consume OAuth should also provide it (like Stack Exchange).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> Anyone have a good explanation of why, in the Python example, they recommend `hmac.compare_digest` instead of `==` for comparison?

Is there something obvious I'm missing here?

<comment><USER34> == in python will stop comparing after the first character mismatch. You can use that fact to test byte by byte your password knowing that the more good characters you have, the longer the comparison will take, which is called a timing attack.

hmac.compare_digest is a constant time compare, in that no matter if there is a match or not, it will take the same amount of time.

<comment><USER35> Timing attacks aren't useful against password hashes, but avoiding them is a good habit to be in.

<comment><USER36> This is "mostly true" but with an edge case...

If the attacker knows which algorithm and work factor you're utilising and your system doesn't use randomly generated per user salts (or an unknown pepper) then theoretically an attacker could use a hash timing attack, combined with a rainbow table, to massively reduce the scope of a user's potential password.

For example, let's say your rainbow table has 20 million password-hash combinations and your hash length is 33 letters, for every letter I know I could drop literally millions of hashes I know it ISN'T. With just the first four letters I could drop it by almost 60% (although my maths here might be completely wrong, it is actually pretty complicated to determine). But there's no real limit on how many letters you could drop from the hash with a timing attack, you could turn someone's password into a 1 in 62 chance.

The TL;DR: Use a per user salt. But a timing immune comparison definitely is "defense in depth" in case there is a bug elsewhere that breaks salts.

<comment><USER35> I chose the words "password hash" carefully. If you're using a secure password hash, you're not worrying about salts, because they take care of randomization for you. If you are worrying about salts, you probably have bigger problems than memcmp timing.

<comment><USER36> I literally don't understand what it is you're getting at.

Password hashing has existed since at least the 1970s and until the 2000s salting wasn't common. While some hashing libraries do insist on you supplying a salt, it is still ultimately up to the application developer to generate and store the salt for later usage.

Therefore it is still common for an application developer to "worry about salts" even if just for storage and generation reasons.

Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, and they're definitely still in the realm of a "password hash." Plus some wonderful developers hard code the salt (salt = "secret") which too could leave them vulnerable to timing attacks if an attacker knew what hashing algorithm and workfactor (e.g. the default) was in usage.

<comment><USER24> > I literally don't understand what it is you're getting at.

I truly hope this will help then: [https://paragonie.com/blog/2015/08/you- wouldnt-base64-a-pass...](https://paragonie.com/blog/2015/08/you-wouldnt- base64-a-password-cryptography-decoded)

"Password hashing" is its own compound noun. The acceptable algorithms (as defined in the blog post this HN thread is about) take care of this for you.

> Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, > and they're definitely still in the realm of a "password hash."

3DES is a block cipher. MD5 is a crytographic hash. Neither of them are password hashes.

> Plus some wonderful developers hard code the salt (salt = "secret") which > too could leave them vulnerable to timing attacks if an attacker knew what > hashing algorithm and workfactor (e.g. the default) was in usage.

What you're describing is closer to a "pepper".

[http://blog.ircmaxell.com/2012/04/properly-salting- passwords...](http://blog.ircmaxell.com/2012/04/properly-salting-passwords- case-against.html)

<comment><USER36> > 3DES is a block cipher. MD5 is a crytographic hash.

3DES is both a block cipher and a cryptographic hash. At least UNIX thought so in the 1990s as many MANY people were storing UNIX passwords in 3DES, DES, MD5, and similar.

> Neither of them are password hashes.

25 years of computing history would disagree with you. MD5 was the defacto standard for password hashing for almost fifteen years.

But no doubt you'd playing silly word games, and are going with your own definition of "password hash" that includes or excludes different hashing algorithms as it is convenient for you. I won't get drawn into that.

> What you're describing is closer to a "pepper".

What you're doing is called being "condescending." You know full well from my posts above that I am familiar with salt/peppering/hashing, and the different technologies involved. So linking to 101 tutorials and definitions of basic terms is only intended to aggravate.

<comment><USER37> To be honest I'd probably interpret them as being antagonistic if the same statements were directed at me (and quoting never helps either) but I think if you take a charitable interpretation it doesn't read that way. I think it's just a direct/technical challenge/debate sort of reply and it's really easy to read into those when you're on the receiving end of them.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> For some reason the article completely fails to link to libsodium: [https://download.libsodium.org/doc/](https://download.libsodium.org/doc/)

<comment><USER24> > For some reason the article completely fails to link to libsodium: > [https://download.libsodium.org/doc/](https://download.libsodium.org/doc/)

The "bindings for most programming languages" link goes to the libsodium documentation, but I'll add a link in more contexts.

<comment><USER39> The article offers specific advice for Java-without-libsodium, but it offers no such specific advice for Java-with-libsodium.

There would appear to be three distinct Java bindings of libsodium.

<comment><USER24> (I'm not ignoring your comment, I'm currently debating whether to update it to include libsodium example code or to write a separate post for that.)

<comment><USER40> Write a separate post and then link to that from your current post. Best of both worlds :D

</comment></comment></comment></comment></comment><comment><USER41> I have always been impressed by the way django does it.

[https://docs.djangoproject.com/en/1.9/topics/auth/passwords/](https://docs.djangoproject.com/en/1.9/topics/auth/passwords/)

</comment><comment><USER42> Assuming this is legit (seems like it), mega bonus points for walking through examples on the various platforms/languages.

</comment><comment><USER43> From previous discussions about this topic, I had noted down the following best practices:

Passwords should be scrypt'ed on client, and then, the server should generate a SHA256 hash of the scrypt'ed hash and store that in DB.

\- Running CPU & memory heavy scrypt hashing on the client side will allow us to use bigger hashing work-loads.

\- EDIT: Removing the MITM point, because as many said, that's the job of TLS anyway.

\- External brute force attackers will have to take the burden of heavy hashing. No DOSing through scrypt.

\- Storing SHA256 hash instead of scrypt hash on DB means even if DB is stolen, attackers can't use stolen scrypt hashes to authenticate any client.

I would love to get others' feedback on this. EDIT: Found the reference: [https://news.ycombinator.com/item?id=9305504](https://news.ycombinator.com/item?id=9305504)

<comment><USER24> How are you going to calculate the scrypt hash, client-side?

Doesn't that scrypt hash then become the password, from the server-side application's perspective?

How are you storing the salt for the user if your server only knows about a SHA-256 hash.

> MITM attacks won't get access to unencrypted fields.

That's TLS's job. If you, for example, are building a web app and you're delivering Javascript to perform the scrypt calculation, a MitM can replace the code to exfiltrate the user's plaintext password. It doesn't make sense for the threat model.

<comment><USER44> I think the idea is that the scrypt hash does become the password, but it's a _better_ password. A password with a lot more entropy (kinda). The increased kinda-sorta entropy makes the use of a slow key derivation function on the server side unnecessary, so SHA-256 becomes sufficient.

Not sure how I feel about it.

<comment><USER24> I feel that this is needlessly dangerous, personally.

How are the salts managed? This detail is important. SHA256(scrypt(password, constant_value_instead_of_salt)) is going to produce collisions in the stored hash.

<comment><USER45> I think he's going for SHA256(scrypt(password, salt, work_factor)) and saying the bare SHA256 is sufficient. As opposed to SHA256(salt+scrypt(password, salt, work_factor)).

I think it's dangerous because of the dependence on the client, and useless because scrypt(password,salt,work_factor) on the server is plenty hard to attack.

<comment><USER46> > scrypt(password,salt,work_factor) on the server is plenty hard to attack

For a large enough work_factor. In practice "large enough" is usually interpreted to mean "something that seems safe without being so large that I need to buy lots more servers"

The argument (which I'm interested in, but not yet sold on) is that moving the scrypt to the client allows you to pump up the work_factor even higher than you would have been willing to do on the server.

<comment><USER45> After thinking about it more the concept is interesting, but the main fear I have is that doing it in a web browser with JS is next to impossible to secure. Maybe if vendors got on board...

In general though, pushing auth down to clients in Javascript makes my skin crawl. You're one XSS away from having an attacker no-op your scrypt and return SHA256("secret-attacker-password") on registration. The logical follow- up to that: 'have the server run scrypt the first time' \-- but then you've just moved the tough work to user registration, which seems just as exploitable.

I dunno. Safe crypto is hard enough already; I'm not sure pushing it into Javascript on the browser makes it any easier.

<comment><USER46> The proposals I've see have always had the initial scrypt be done on the server.

The DOS risk on registration can be mitigated more easily than the login one. e.g. Rate limiting new registrations will often be more palatable than limiting logins, or you can require "email validation" before you set the first password. And, not every application allows self registration.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER47> Wish there was a site where it lists algorithms and gives a table, and an ability to compare it to x years ago:

algorith | fairly safe difficulty (all variables) | very safe difficulty without incurring too much performance cost.

pbkdf + sha1 | completely unsafe | completely unsafe

pbkdf + sha2 | 100000 | ...

pbkdf + sha256

bcrypt

scrypt

argon2

<comment><USER35> PBKDF2-SHA1 is safe.

That's the problem with a chart like this. The gradation will go from "completely unsafe" salted hashes to "very much safe enough" with only marginal changes after that.

Another problem is that these functions are all parameterized, so the chart needs to capture the safety level at specific parameters.

<comment><USER47> My goal was to create a chart of:

algorith | a safe set of parameters | a VERY safe set of parameters but needs strong hardware

Maybe a 4th column of "unsafe if difficulty is below"

This could be something updated yearly or whatever to help people figure out what things they need to move towards. If they see that their currently used settings are below the unsafe line, they will know it's time to upgrade.

Example: I use PBKDF2-SHA1 at difficulty of 11k iterations. Is that number still within the "probably okay" list, or is that in the "I can hack any password on your list in 15 minutes"

</comment></comment></comment><comment><USER24> I'm part of the Paragon Initiative Enterprises team and have access to edit the blog. If you have any questions (AMA) or would like to suggest any additions, please let me know.

<comment><USER48> We really appreciate the post, thanks! Not a suggestion for this topic, but would love a future post on request signing in 2016 (think HMAC). In particular there are so many JSON REST APIs these days going over HTTPS that it's hard to determine best practices and what's overkill.

<comment><USER24> Thanks for the suggestion, I'll put it on the list. :)

</comment></comment></comment><comment><USER49> Perl programmers should try this module: Crypt::ScryptKDF I have been using it for a while now

<comment><USER50> And with DBIx::Class it is almost easier to do it right[1] than wrong.

[1] [https://blog.afoolishmanifesto.com/posts/do-passwords- right/](https://blog.afoolishmanifesto.com/posts/do-passwords-right/)

</comment></comment><comment><USER51> What I find frustrating is the lack of availability of most of these algorithms for the most common platforms (.net, php, java). The author recommendation seems to be driven by availability, not the algorithms own merits.

<comment><USER24> If you're using any of: PBKDF2, Bcrypt, Scrypt, Argon2, then you're fine. Our recommendation is:

        1. Use the best option available, but
        2. We provided example code in multiple languages for the
           best one that's widely available

</comment></comment><comment><USER52> I believe the Ruby example is incorrect: When checking a password's validity, you must use a constant-time comparison or else you are exposing a vulnerability to side-channel timing attacks.

There is an open issue in Coda Hale's bcrypt repo about this: [https://github.com/codahale/bcrypt- ruby/pull/119](https://github.com/codahale/bcrypt-ruby/pull/119)

My stance on posting "best practice" articles is: you must follow _all_ best practices in them.

<Edited for clarity>

<comment><USER24> > I believe the Ruby example is incorrect

Unfortunately, there's nothing I can do about that, unless someone can point me to an alternative that uses a constant-time comparison.

I've left a comment on the pull request so that, hopefully, it can be merged.

> (and likely others)

Which others?

<comment><USER52> After re-reading the others in depth, all other examples appear to use appropriate comparison methods (knowing nothing of the underlying implementations). I've updated my comment to clarify.

I see your team is actively posting on the bcrypt-ruby issue #119 as we speak, so I guess I'd say wait for the PR to merge, or manually implement the approach they've outlined to secure compare: [https://github.com/codahale/bcrypt- ruby/pull/119/files](https://github.com/codahale/bcrypt-ruby/pull/119/files)

</comment></comment></comment><comment><USER53> Hashicorp's Vault (vaultproject.io) is also an excellent way of controlling access to secrets and back ends, such as PostgreSQL.

It's worth spending the time to learn, implement, and integrate into the security best practices you should already be deploying.

</comment><comment><USER54> Here's yesterday's discussion for the exact same post (maybe the duplicate search failed this time?)

[https://news.ycombinator.com/item?id=11108481](https://news.ycombinator.com/item?id=11108481)

</comment><comment><USER55> > PBKDF2 (nearly everyone except FIPS agrees this is the worst of the > acceptable options)

is that true?

<comment><USER35> Only in the most technical sense: cycle for cycle, PBKDF2 gets you the smallest amount of protection from that group of password hashes. PBKDF2 is still vastly better than non- password hashes like salted SHA.

<comment><USER56> You say that "PBKDF2 is still vastly better than non-password hashes like salted SHA", but is PBKDF2 (with >10,000 iterations using SHA512 and a random salt, for example) secure enough?

</comment></comment></comment><comment><USER57> Or, we could move to not storing passwords at all, viz client certs and SRP.

<comment><USER35> SRP still stores crackable password verifiers, and is tricky to implement safely.

<comment><USER57> Crackable in what way?

Of course the core of it could be upgraded, but the idea is sound. Sounds like you could say the same thing about using a DES-based hash. "Don't Hash! It's weak!" is throwing the baby out with the bath water.

<comment><USER35> In exactly the same way as any other password hash is cracked.

<comment><USER57> By iterating over all passwords? That seems like the definition of a good password storage if that's the only way! I mean, you can make the same complaint against anything; it's meaningless by definition.

Sure, public-private pairs are more difficult (to impossible) to brute force once they're so long, but srp, bcrypt, pbkdf2 &c are pretty good when you want/need a password. Srp being superior in that your secret never leaves your computer.

<comment><USER35> I'm not following you. The whole point of a password hash is to (1) admit only that one brute-force attack, and then (2) to slow that attack down as much as possible.

SRP gets you (1), but is inferior to every other modern password hash on (2). SRP is better on (2) than other PAKEs (it's an "augmented" PAKE because it tries to slow down brute force), but password hashes have (2) as their whole objective, and total design freedom.

You can combine PAKEs and password hash concepts. But for the purposes of _password storage_ , SRP isn't buying you anything (except for a bunch of possible crypto bugs that will gameover your project).

SRP is a bad call for virtually all projects. Or, maybe a better way to say that is, "if you have to ask, don't use SRP."

<comment><USER57> > but password hashes have (2) as their whole objective,

Only until that was what people cared about. How long, and how many still, use single-round md5 and sha for password storage?

SRP is an old algorithm -- it could be strengthened significantly with little love. (Similar as to how took a little care from the community for bcrypt, pbkdf2, &c have become the "norm" over md5.)

> SRP isn't buying you anything

SRP is buying you the ability for the server to never have the password, a secret value you're handing someone else!

> SRP is a bad call for virtually all projects. Or, maybe a better way to say > that is, "if you have to ask, don't use SRP."

I still feel like you're throwing the baby out with the bathwater. Just because something can be updated and hasn't (like using a weak hash like md5), doesn't mean the core concept is bad (using a 1-way hash function).

<comment><USER35> No, it isn't. It's storing verifiers with the same power for attackers as scrypt, except that scrypt's verifiers are harder to crack.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER58> I kind of don't like this article. I think we should be teaching people best practice for securing and storing a password, not simply giving them a library.

</comment><comment><USER59> I believe that the safest way is not to save them. Instead, outsource this to a few select OAuth providers which you and your customers are willing to trust.

<comment><USER60> What do you do about sites where the users don't particularly likely said providers? Not everyone uses Facebook or Google or Twitter after all, and a lot more would rather use an anonymous disposable account than one tied to an existing identity.

There's also the fact said systems seem to be a nice target for spammers. They're popular, so they're often attacked. And because they're often attacked, their anti spam defences don't usually last very long. So any spammer now has a nice way to get an account on near enough any site they like, while with a standalone system, they'd at least have to tailor their attacks to the site in question.

There's also the fact it silos much of the internet (or at least user information) within the systems of a few large providers, which gives a significant amount of control to said providers.

<comment><USER59> > Not everyone uses Facebook or Google or Twitter after all

Yep, I do tailor the selection of oauth providers to my audience. E.g., an app for devs = google, github, and gitlab.

</comment></comment></comment><comment><USER61> Ruby's argon2 gem is pretty good!

</comment><comment><USER62> "How to Safely Store a Password in 2016"

Don't. Unless it's 100% absolutely necessary.

If you must, continue reading on.

<comment><USER63> The article inaccurately describes generating a password hash & using it as "storing a password".

<comment><USER62> My point is simply if you can avoid storing user credentials, avoid storing their credentials.

For many services, the most valuable data they contain happens to be the user credentials that the service uses to authenticate the identity of the user. If you assume that users share their credentials across multiple services, if your system is attacked, and you improperly stored their credentials, you've caused way more damage, than the data you were trying to secure.

For example, take your run of the mill online todo app. If an attacker got access to the all the todos, vs an attacker got access to the all the todos _and_ all the user passwords (even if securely stored). What is more valuable to an attacker?

<comment><USER64> I agree that it's better to avoid storing user credentials, but what do you suggest instead to authenticate the user?

<comment><USER62> If you don't require privileged elevation, then I'm a fan of just using an email address and send "magic links" \+ persistent (but expiring) sessions.

For mobile apps, I think using SMS and One-Time Passwords is sufficient as well.

You can also use a delegated auth system put in place by OAuth v2, or something like Google Accounts, Twitter, etc. Those services do get pushback, as not every uses Gmail (or likes to give any run of the mill app access to Google account data).

<comment><USER64> > If you don't require privileged elevation

What do you mean by privileged elevation (I'm talking in the context of a web app)?

> just using an email address and send "magic links" \+ persistent (but > expiring) sessions

Do you mean something similar to what Medium does?

[https://medium.com/the-story/signing-in-to-medium-by- email-a...](https://medium.com/the-story/signing-in-to-medium-by-email- aacc21134fcd)

I like it too. But what about delays in receiving emails (when I suggested this approach to some customers, they were worried about that)?

> You can also use a delegated auth system

Yes, outsourcing the authentication is another solution, but some (most?) users are not comfortable with giving so much power to Google/Twitter/GitHub/etc. (as you wrote in your comment).

<comment><USER62> > What do you mean by privileged elevation (I'm talking in the context of a > web app)?

For example, prior to changing account settings, reauthenticate the users, regardless if they have a valid session.

> I like it too. But what about delays in receiving emails (when I suggested > this approach to some customers, they were worried about that)?

Combo of email & SMS.

As Bruce Schneier has written, security is usually a trade off of user experience.

<comment><USER64> > For example, prior to changing account settings, reauthenticate the users, > regardless if they have a valid session.

Why not reauthenticate by sending a one time password by email/SMS (instead of asking for a password)?

> Combo of email & SMS.

Good idea. I was also thinking of sending one time passwords through some chat applications like WhatsApp, but most of them have no API for such a thing (except Telegram).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER65> Storing passwords is like storing credit card numbers - just don't do it

</comment><comment><USER66> I'm curious if any D developers care to share their approach to this?

</comment><comment><USER67> Does Argon2 have an official website and repo or is it just the PHC repo?

<comment><USER24> [https://github.com/P-H-C/phc-winner-argon2](https://github.com/P-H-C/phc- winner-argon2) is the official repo.

</comment></comment><comment><USER68> For anyone who reads the comments before clicking the article, the subject is storing your users' passwords, not managing your passwords for a variety of services. I had interpreted it as the latter. A better title might be "How to Safely Store Your Users' Passwords in 2016".

(Title is currently: "How to Safely Store a Password in 2016")

<comment><USER69> great, thanks. because i was about to reply with "on a piece of paper in the same place you store your diamonds"

<comment><USER70> I'm starting to think that if you're a security-conscious person and understand what's at stake, then the best solution for you would be to simply memorize it. Your mind is the only place from which an attacker can't steal your password without drugging you or beating you up until you give it out.

<comment><USER71> The main limitation of that is that your passwords are limited to what you can memorize. Which, for most people, is not very much. Even for just one password, never mind for multiple services. I think if you're a pragmatic security conscious person you'd weigh the trade offs...and I thinking of it as just "simply memorize it" opens you up to other problems.

<comment><USER70> Yes, I know. But I was thinking about serious people, not general population. Most people are not willing to expend more than 2 seconds of effort before deciding "it's not working, I need to make it simpler / write it down". They don't notice that they probably still remember things like their first girlfriend's phone number, or any random string they've been typing in more than 10 times a day. If you put even half the effort into memorizing something as most do into picking and maintaining e.g. password managers, you'll find that your memory is a better tool than you expected.

People used to memorize whole books.

</comment></comment></comment></comment></comment><comment><USER72> I use an ultra secure method for my passwords, it is 100% unhackable.

Proprietary Analog Password Encryption Routines.

<comment><USER24> That's not very useful for web programmers that are handling their users' passwords, is it?

</comment></comment><comment><USER73> Lame title. Story talks about storing password hashes and not passwords. I'm still looking for a solution to storing actual user passwords. Scenario: All laptops in the company have a unique local administrator password. How do I manage this effectively as a domain admin?

<comment><USER74> Use a password manager of some kind. Lastpass is nice, and has an enterprise component that lets you share passwords with co-workers or teams.</comment></comment>


Texas Power Prices Briefly Surpass $9k Amid Scorching Heat - <AUTHOR> https://www.bloomberg.com/news/articles/2019-08-12/searing-texas-heat-pushes-power-prices-to-near-record-levels <comment><USER2> If it's incredibly hot, doesn't that also mean it's incredibly sunny? Sounds like solar would be the perfect solution here. In Australia, energy prices sometimes go negative because of the abundance of solar energy[0]. Admittedly not during the hottest days when everybody turns up the AC, but using solar to supply that energy still seems like the most logical approach.

Of course alternating between extremely high and negative prices due to the volatility in supply and demand should create plenty of opportunity for businesses that make money simply storing energy and evening out the fluctuation.

[0] [https://reneweconomy.com.au/wind-solar-push-south- australia-...](https://reneweconomy.com.au/wind-solar-push-south-australia- prices-below-zero-for-almost-six-hours-39546/)

<comment><USER3> One problem is that solar's peak is too early in the day to match peak demand in most of the US (including Texas). Texas's electricity usage typically peaks around 4-6pm in the summer, while photovoltaic output peaks around 12-2pm. There is some storage, but you would need a lot more to line those curves up. A cost-effective way to shift the solar peak to about 4 hours later _would_ definitely help on a lot of days.

For the curious, you can browse the demand curves day-by-day here: [https://www.eia.gov/realtime_grid/#/summary/demand?end=20190...](https://www.eia.gov/realtime_grid/#/summary/demand?end=20190812&start=20190714&regions=0000000000000000001)

<comment><USER4> This is where stationary storage (via batteries) makes a lot more sense. In Australia, the same problem exists, but they have an giant ozone hole so even more UV hits the surface. Tesla deployed what (at the time) was the biggest battery storage project in the world. They built a 100MW/129MWh battery setup with their Powerpacks. In another part of Australia, they're deploying a "virtual power plant" by equipping up to 50,000 homes with individual home battery backups via Tesla's Powerwall product. The grid operator will be able to tap into each of these batteries to redirect power to the grid or shift load off of the grid whenever they see necessary. This is resulting in massively improved prices for electricity in South Australia where they had a lot of rolling blackouts (due to the heat) last summer.

The newly released Tesla Megapack [https://www.tesla.com/megapack](https://www.tesla.com/megapack) seems like a slam dunk for this sort of thing. You store that crazy amount of sunshine that is excess in batteries and use them that evening or the following morning. The economics of this approach are becoming more and more realistic due to better technology and better manufacturing.

<comment><USER5> The problem in urban Texas is that all the asphalt and concrete acts as a stationary _heat_ battery. Counteracting that is a huge part of the problem.

They could use batteries and air conditioning to do so, but it's likely the return on investment would be higher figuring out how to provide more shade even in non residential areas.

<comment><USER6> It's a shame we can't convert that heat to electricity in some efficient way.

<comment><USER7> Oh we can convert high grade heat to electricity with amazing efficiency. Problem is, this is super low-grade (low temperature) heat. Darn you, thermodynamics.

</comment></comment></comment></comment></comment></comment><comment><USER8> A friend of mine who works from home was trying to get me to switch to Griddy which offers pass-through market prices at 15 minute increments. Today his electric bill was $9 and that was after he turned off literally everything except his fridge. He even turned off his hot water heater.

We only had 3% capacity left in the system, yet out in the Permian Basin operators are flaring off excess gas because they have no access to pipelines or choose not to pay for it. *1

Until the Texas Railroad Commission stops allowing flaring permits and forces operators to connect the energy of all that gas is wasted, which is a damn shame.

We could definitely use that gas (after processing) to run peakers until better storage comes online. But how do you sell the idea of investment to flatten energy prices in an unregulated market?

(1) [https://oilprice.com/Energy/Natural-Gas/Gas-Flaring- Running-...](https://oilprice.com/Energy/Natural-Gas/Gas-Flaring-Running- Rampant-In-The-Permian.html#)

<comment><USER9> You know what's worse than the gas flare offs? Nearly 100% of solar power, of which there is a tremendous amount in Texas in the summer, is going to waste. Most of the wind, of which there's a lot in the plains of west Texas and the hills of central Texas, is also wasted.

The only reason Texas isn't producing nearly 100% of its power from renewable sources today is because the oil and gas industry has been coddled and protected and catered to by the state government for decades, at the expense of everyone who isn't employed by the oil and gas industry (which, admittedly, is a lot of people in Texas).

<comment><USER10> So why is said oil and gas industry not investing in solar power themselves? I mean they will be left behind at some point if they don't catch up now.

And whatever happened to the free market? If an investor wants to plop down a solar collector farm somewhere in Texas' vast lands, what's stopping him? The government?

<comment><USER11> Ghengis Khan doesn't look around at his pillaged kingdom and think: "i guess this is enough, maybe we should establish more competition to enhance our long-term success as a community."

No. He keeps chewing on brisket until someone else forces the issue.

<comment><USER12> I don't believe these huge oil/gas companies are this naive. If just one makes the plunge and has success then all the others would have to follow. I don't think any of these oil companies are a Kodak.

<comment><USER13> If you mean not naive in the sense that Exxon knew of the effects of the emissions they helped create and continued with no change except for spreading disinformation: you are correct, they aren't naive.

</comment></comment></comment></comment></comment></comment><comment><USER14> That's over ~$750 for the power stored in a single Tesla battery pack. Not that the cars are capable of back-feeding the grid (V2G), unfortunately, nor is the infrastructure in place to pull from them in times like this...

It sure seems like if we're going to have millions of these 100kWh batteries plugged in, all nicely geographically distributed and internet connected, it would be swell if the owners could set a price at which they would be willing to sell their energy. It would just add another way that EVs are better than ICE cars.

<comment><USER15> Over time it might be more practical for EV manufacturers to take back decommissioned vehicles and install the battery packs in centralized facilities for grid storage and stabilization. That would avoid the need for expensive and complex grid connection equipment in individual EVs. Even if the reused batteries are down to 60% capacity, stacking a bunch of them could deliver enough power for demand spikes.

<comment><USER16> Are you a battery engineer? My understanding is the EoL for Li Ion batteries is when they are at 80%. Below that, their internal resistance is too great to do anything useful with.

<comment><USER17> As someone recycling old laptop cells that are decades old (even got a few sony fukushima ones in last batch). Having a absolute large amount of them can cancel this out. Sure one fresh cell might have the small top current than 10 parallel old ones due to resistance, but if space is no concern the older ones are really great economically.

</comment></comment></comment></comment><comment><USER18> > This week's price spikes also underscore how dependent the region's power > grid has become on wind farms, which now make up about a quarter of the > generation capacity in Texas. Lackluster breezes have contributed to the > higher prices, Hehir said.

> Wind power generation in the region has plunged for three straight days, > grid data compiled by Bloomberg show.

This happened in Australia earlier in the year. It's going to keep on happening, as long as the industry fails to account for the variance in output by wind power.

<comment><USER19> And the all-in cost of wind will be much greater when accounting for the gas support they require.

<comment><USER20> Which kind of gas? Base load gas yes, but not new gas peakers - solar+batteries is already cheaper than peakers. The problem is Texas is not a solar-friendly state, it will be hard for non-fossil/non-wind sources to penetrate heavily.

</comment></comment></comment><comment><USER21> For reference, $9k is roughly 300x the "normal" price.

<comment><USER22> Here's a chart for a quick visualisation:

[http://www.energyonline.com/Data/GenericData.aspx?DataId=4](http://www.energyonline.com/Data/GenericData.aspx?DataId=4)

[https://imgur.com/a/6gfF5NI](https://imgur.com/a/6gfF5NI)

Also such bumps do happen somewhat regularly (which is concerning), but this one was by far the largest recently:

[https://imgur.com/a/kj9Okjt](https://imgur.com/a/kj9Okjt)

<comment><USER23> $9k is fairly artificial in that it comes from the $9k ERCOT ORDC (operations reserves demand curve) meaning they did a study awhile back looking at Texas GDP and the cost of lost load and judge it to be ~$9k per MWh. This means when the optimization software has a shortage of their operating reserves the prices jump up to that level.

</comment></comment></comment><comment><USER24> Are American electricity prices usually given as USD per Megawatt-hour? Because I found the headline wholeheartedly useless without knowing what the unit of energy was.

<comment><USER25> In Canada I had per KWh (same as in most of Europe I think), so yes, I found this completely useless. Maybe they just wanted to say it's over 9000 because of the meme.

<comment><USER26> 1 Mega = 1000 Kilo

So a price of $9000 per MWh is $9 per KWh.

<comment><USER25> Obviously, it's missing in the title is the point, not the unit used.

<comment><USER27> You're calling an article 'useless' because you have to open it to know the unit? That's pretty extreme.

Would you be complaining if it was "Texas Power Prices Spike Amid Scorching Heat"? Or "Texas Power Prices Max Out Amid Scorching Heat"? I think both those titles are fine, and they give about the same amount of information.

<comment><USER25> I was replying to a comment on the headline being useless. It's normal in English not to repeat something in a reply.

To spell it out. It's completely useless to mention $9k in the headline if you don't mention per how many units of energy.

Your suggested titles are IMHO better since they use qualitative language instead of a quantity with no reference point.

<comment><USER27> If you want to say the number inside the headline is useless, I won't argue.

But you were agreeing with a claim that the _headline itself_ was useless. That's not the same thing.

If the headline was useful without the number, which you seem to agree with[1], then the headline is still useful with the number. It's like adding an extra filler word to a sentence. The word is useless, but it doesn't ruin the sentence it's inside of.

[1] Note that the original headline already had qualitative information, and made it clear that this number was unusually high. It's not qualitative vs. quantitative, it's qualitative vs. both.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> This is the spot price in an extremely seasonal futures market. This article is clickbait garbage.

I have a few clients in this space. Texas, through ERCOT is a deregulated market. The "electricity company" or REP (retail electricity provider) merely purchases futures from ERCOT (the market maker) and bills you for your usage according to the pricing plan you have with them. In the end your provider must purchase from ERCOT at least as many MWh as their customers use.

Distribution and maintenance is handled by various regional companies and factored into the price by ERCOT

The market price is like a futures auction, of a commodity where demand peaks in August. This is why the spot price can be so ridiculous.

The thing is, nobody pays the spot price. If a REP must pay the spot price in August (because of inadequate hedging) they almost always immediately become insolvent. It's the "third rail" of this industry, touch it and you die. At that point secondary measures kick in to ensure those customers are not without power.

If you have more questions please reply.

<comment><USER29> You mention that "nobody pays the spot price" but what effect does this price have then if nobody pays it?

If I have a way to make, let's say, 30MW for up to 5 hours per day, and inject it into that system, could I get $9000 per MWh for that power during the period mentioned in the article?

If I wouldn't get $9000 then what purpose does this price signal have? "Oh great, the notional price I won't actually get paid went up. I will be sure to increase the notional amount of electricity I don't actually make"

<comment><USER28> A few REP's pay that price each year.... and they go out of business.

The price is a reflection of the scarcity of generation and transmission capacity when its 101°F at 90% humidity and the entire state has the A/C on full blast.

If you were plugged in with ERCOT as a generator (guessing you don't have the millions to build one), and you were the last to get told to start up, and you were close to the source of the need, you most certainly could earn that much. That's what "peaker plants" are. You've probably heard about how bad they pollute.

Oh, and that price might only last for 15 minutes.

If you're generating electricity "behind the meter" (from solar panels) they usually agree to some nominal price but chances are if it's that hot your system is using your panels to augment your grid usage.

<comment><USER29> This makes more sense, thanks. I do have a further question though.

You say you'd get this price if you're last but surely it would make more sense to pay all generators the current winning price otherwise there's an incentive to guess and under-supply to get paid more.

I know the UK had to iterate a few times to make a system that wouldn't get gamed by suppliers, ensuring their incentives align with the power network stability and performance goals.

I've actually been reading recently about the other side of this, the retail side would like to force consumers to accept 15 minute metering. Current legislation forces consumers to be metered in hour increments, with 15 minutes only at their option but that might mean suppliers eat a spike like this one. Most home users are actually paying a fixed rate or simple on peak/ off peak system, with their off peak supply locally switched off by relays during peak times, but the law already provides for hourly rates. The long term idea is to load shed home users. Power spikes? Stop filling up those EVs and heating swimming pools rather than spin up another gas turbine.

<comment><USER28> The generators can't just do whatever they want, otherwise they could easily conspire to set prices.

ERCOT, MISO (mid-continent system operator), and CALISO (California) basically run the grid. The generators are all under contract and can be fined for not being able to spin up when asked. This is called an "unplanned outage" and it can really cause problems.

</comment></comment></comment></comment></comment><comment><USER30> Seems like solar power would be perfect for this situation, maximum production at time of greatest use.

And Texas has plenty of land where putting in massive solar plants would do little ecological damage.

</comment><comment><USER31> $9K / MWh for those who are curious. ($ alone as a unit is meaningless.)

<comment><USER32> $9 per kWh is pretty out there.

</comment></comment><comment><USER33> Wasn't Texas also where the price went negative over the spring?

<comment><USER34> That's what happens in markets with a lot of wind generation,

South Australia saw a 14000/mwh price for 5 hours earlier this year (Due to a 48 Celsius heat wave).

Hot days and wind generation are not correlated unfortunately.

<comment><USER35> Isn't the Texas grid largely isolated, with only minimal connections to the two major multi state grids that the other states connect to? I'd guess that also contributes by limiting their options for dealing with excess when demand is low or shortages when demand is high.

</comment></comment></comment><comment><USER36> Guessing that breaks down to something like $30-$40 per hour per home? Wow.

<comment><USER37> Some fun numbers (@ $9/kwh):

Running a 1kw microwave costs 15 cents a minute.

Watching a 2 hour movie on a 65" TV costs a dollar.

Playing a PS4 is $2/hr.

Edit: Added @9/kwh because it wasn't clear that's what I was using in my calculations

<comment><USER38> A 1500W microwave at 10 cents/kWh will cost 15 cents per hour. A 65" TV might use 100W, 2 hours a day would cost you $6 a year.

A refrigerator will get you because it's running 10 hours a day. Much bigger, is the giant heat sink that is your water heater.

<comment><USER39> The spike here was to $9/kWh.

100W * 2 hours * ($9 / (Kilowatt * Hour) = $1.80

</comment></comment></comment></comment><comment><USER40> Running a diesel generator cheaper than $9/kW.

<comment><USER41> So is a gasoline generator. A Honda EU3000is costs around $0.50/kWh to run, excluding depreciation.

<comment><USER42> For something that is used a few hours per year the dominant cost is the capital cost, and not the marginal cost (fuel + wear&tear).

</comment></comment></comment><comment><USER43> How hard would it be to run large hvdc lines across time zones and pipe energy between areas with complimenting renewables?

<comment><USER44> Texas has an independent power grid unlike the rest of the US.

It's an odd choice, it helps then in some ways, but hurts in others.

<comment><USER45> I guess that's a repercussion from the succession. It was a long time ago, but I'm sure there were many people in positions of power that still held those viewpoints and wanted to keep everything separate for when that (in their minds) inevitable day comes again.

<comment><USER46> My understanding is that it is a side effect of WWII. Texas had a large amount of plants needing redundancy. Afterwards, ERCOT's independence allowed the state to bypass a significant amount of FERC oversight and regulation.

</comment></comment></comment></comment><comment><USER47> One would think it would be a slam dunk high profit business opportunity - come to TX, buy a cheap land, put solar panels and large battery, throw a power cable to the electric grid ... and just relax and watch the Niagara of money flowing into your bank account. It is pretty informative to meditate upon why such business opportunity is just a fantasy incompatible with the current reality.

<comment><USER48> People are preparing to do just that:

"Texas' solar market is about to catch fire"

 _With more than 5 GW of approved solar projects in the ERCOT grid, Texas is getting ready for a major boom in its utility-scale solar market._

[https://pv-magazine-usa.com/2019/02/11/texas-solar-market-is...](https://pv- magazine-usa.com/2019/02/11/texas-solar-market-is-about-to-catch-fire/)

Though the Niagara of money is going to be more like a modest rivulet of money since prices like these happen only a few hours a year, and Texas generally has low wholesale electricity prices.

</comment></comment><comment><USER49> Can you use the heat differential of underground former oil mines to pump the heat into?

</comment><comment><USER50> Is there a photovoltaic tech the uses infrared to take advantage directly of the heat?

<comment><USER27> The maximum energy you can extract from a unit of heat is based on the temperature ratio of your hot object and your cold object.

For light coming from the sun, the hot object is 6000K and the cold object is around 300K. So about 95% of the energy is available to attempt to capture. 94% if your solar panel gets very hot.

The infrared coming off local hot objects is almost useless in comparison. If you can keep your infrared-catcher perfectly cooled with an underground loop, it will be at 290K. If you have an object that's all the way up at 150F, that's still only 340K and less than 15% of that energy could possibly be captured.

</comment></comment><comment><USER51> Perhaps ycombinator should find team who can build the shipstone.

</comment><comment><USER52> It sounds as though there is a hell of a market for energy storage in Texas. Tesla dropped that battery station into Australia on a very short timeline- they should try that again.

</comment><comment><AUTHOR> Prices went up from a lack of wind and capacity.

If you think solar is the solution stop and think.

Solar occurs during peak demand. You will need more solar then demand. That is a lot of solar.

Also when it gets really hot the wind often stops. Same goes for really cold. Wind farms often have to shutdown in cold conditions because of ice.

</comment><comment><USER53> >The unprecedented market rally highlights how volatile the Texas power market has become as coal-fired power plants, which have seen their profits squeezed by cheap natural gas and renewable energy resources, continue to close. Texas's grid operator has been warning for months that plant retirements and increasing electricity demand has left it with slim supply margins.

>This week's price spikes also underscore how dependent the region's power grid has become on wind farms, which now make up about a quarter of the generation capacity in Texas. Lackluster breezes have contributed to the higher prices, Hehir said.

This is one of the downsides of the push to "green" energy. While wind and solar are great, there can be significant variability. Unfortunately, battery tech is not there yet to help with the supply-demand mismatches.

<comment><USER54> _" Unfortunately, battery tech is not there yet to help with the supply-demand mismatches."_

Isn't this the situation that Elon's battery in South Australia was built to handle? From what I understand, it's been profitable and successful.

\---

Without something to handle soaring peaks, a friend of mine who works in energy described the power landscape as like needing a 100-lane wide bridge to deal with peak-hour crossing a city river.

<comment><USER55> The South Australia battery is profitable because it solves the problem of changes in demand over a period of seconds or minutes, filling the gaps while a larger fossil fuel plant manually ramps up to take over the load.

It's critically important and far more costly to do in other ways.

<comment><USER56> It's not just "seconds and minutes". It can provide 70 MW for 10 minutes and 30 MW for 3 _hours_.

<comment><USER57> From the article, it seems they're dealing with demand fluctuations of 1000-3000 MW within a given hour (2PM was the example), so I think it's really working on a totally different scale. Even 10x as many batteries wouldn't be able to smooth that load fluctuation.

</comment></comment></comment></comment></comment><comment><USER58> One of the biggest skills humanity has to learn soon is global heat management. At the same time it's 100 degrees in Dallas, it's freezing cold in some other part of the world. And in the same place but at a different time of year, the temperature goes down to around 40 degrees. There's got to be a way to even out those fluctuations, and doing so would produce immense benefits: humans are comfortable in 60-70 degree weather, so by moving heat from the hot space/time locations to the frigid ones, we win on both sides of the deal. And by the way, the Second Law of Thermodynamics also wants to smooth out temperature gradients. It's got to be possible.

<comment><USER59> I've wondered as solar gets more popular we'll have heat and cooling systems that take advantage of the free excess electricity.

For example heat my water to 140% the ideal temp and cool a thermal sink for ac when I'm away from home during peak solar.

Then when I'm at home and it's no longer sunny my electricity needs are nil as I utilize the pre stored coolant and heat.

Haven't done the math but I'd assume a 500 gallon water tank that's heated or cooled during peak solar with insulation could be used to keep your home at the perfect temperature by using excess solar.

<comment><USER60> Ideally, use phase changes. A bank of ice will reject a lot more heat than 1C water.

Steam too, but it's better for transport versus storage. You could melt wax if space was at a premium.</comment></comment></comment>


KeyChest – Free HTTPS Expiry Monitoring for 500 Domain Names - <AUTHOR> https://magicofsecurity.com/keychest-supports-free-web-encryption/ <comment><USER2> It's a bit disappointing their demo doesn't appear to leverage certificate transparency logs as a source of truth for which certs are out there and instead relies on pinging the server directly</comment>


Synthego – Biotech – CRISPR – Redwood City, CA – Full-Time and Onsite - <AUTHOR> Hi everyone,
It's good to be back. :-)
Synthego has gone a long way since I last posted here (look us up and find out for yourselves!).
Recap: We bring automation to genome engineering, enabling scientists to run their own fully-automated laboratory at low cost, performing millions of controlled, repeatable experiments per day without human error. We are providers for CRISPR research by manufacturing the highest quality, lowest cost, Synthetic RNA.
We are actively looking for individuals who have broader minds than what's written on paper. We want the talented outliers who usually fall through the cracks so don't hesitate to tell me a little about yourself if you are interested.
- Senior Mechanical Design Engineers | hardcore SolidWorks
- Senior Full-Stack Software Engineers | Python, Javascript, PostgreSQL/MongoDB
- Application Scientists | CRISPR experience is a must
- Dir. Manufacturing | Domain degree or experience is a must
- Maintenance Technician/Engineering Technician | Savvy, motivated, hungry, no degree or experience needed. Show us you love technology and want to be the best version of yourself.
Much more & all detailed job descriptions here --> www.synthego.com/careers
OR
contact me directly: firstname.lastname@example.com
Thank you!! <comment><AUTHOR> [http://www.synthego.com/](http://www.synthego.com/)</comment>