Firebase-tools: auth:import with existing scrypt hashes and hash-key requirement

[jbrantly]

I'm looking into how to import a database of existing scrypt hashed passwords into Firebase. According to the docs and #253, a hash-key is required when importing scrypt hashes. However, according to Wikipedia (and the API of the library I'm currently using) the inputs to scrypt do not include any sort of key. What does hash-key refer to here exactly, or alternatively, what should I specify for this when importing scrypt hashes.

A similar question was also asked on StackOverflow but unfortunately went unanswered.

Thanks!

[mbleigh]

Unfortunately I've just learned that our scrypt implementation is a bit modified from standard and is not currently compatible with scrypt passwords generated elsewhere (it is primarily there to export/import from Firebase Auth itself). I've filed an internal feature to support standard scrypt, and there is a separate internal request to provide additional documentation around user import/export.

Since this is a Firebase Auth issue more than a CLI one, I'm closing this.

[hernandev]

@mbleigh Where to go then?

I could not find any details or what you Scrypt implementation looks like.

So, in this case, Firebase is actually locking in users, right? Since people can export the hashes but there's no documentation of the processes of how to verify them.

[aarti]

@mbleigh I am currently blocked on this issue. Our whole migration is dependent on this. We should not mark an issue close if it is not resolved, would you agree?

[merlinnot]

This limitation is really easy to overcome, take look at my comment in a similar issue:
https://github.com/firebase/firebase-tools/issues/587#issuecomment-355336967

[aarti]

Google needs to provide clear documentation of their internal scrypt algorithm. I am exporting users out of firebase and want to use Golang scrypt library to verify passwords https://godoc.org/golang.org/x/crypto/scrypt

The algorithm should match the RFC

[hernandev]

@aarti That will not work.

They do not follow the RFC and passwords already hashed on their in-house fake SCRYPT is nowhere documented.

So, on my opinion this was acting in bad faith, since users are tricked into seeying hashing parameters and a popular hashing algo on the documentation and just find out too late that's not the real thing and there's not way to migrate passwords out of Firebase without supporting firebase for a long time until all users have logged in at least one.

I had the luck to be curious about crypto enough to test it myself, so I lost some precious days of my time doing scripts that will exports users, coding the login functionality and when the final "can we get out of firebase?" proof was not valid.

As an user, I recommend using firebase auth only for social and storing the passwords yourself, so you can exchange the custom tokens if needed.

That is, if you're luck enough to have figured out this before going production.

Firebase should at least put a BIG RED CAPS warning on the docs about this.

Ideally, they would disclose the actual hashing process.

OBSCURITY IS NOT SECURITY.

So I would never in my life trust a hashing algorithm that only a few people actually knows about.

Firebase could start being more transparent about this. By at least, renaming it FSCRYPT or something like that.

Or just start moving to the standard ARGON2 algo, which is nowadays the recommended way of doing it.

Shame on you Firebase. Shame on you.

[theckman]

FWIW, obscurity is a valid security _layer_ to slow down an attacker. It can't be your only protection, but it's an absolutely reasonable extra bit to help slow someone down.

[hernandev]

@thechenky I need to strongly disagree, just mention it here but I'll try not to pollute to topic anymore.

• Obscurity adds complexity, and complexity is the ultimate enemy of security.
• Obscurity gives a false sense of security since you're "doing something"

On the given case, a valid obscurity approach would have been using the STANDARD scrypt spec and making the params unknow. You get the difference?

Right now, Firebase is doing that could be analog to publishing both private and public keys but hiding RSA.

There is no single way for this to be a good practice.

The moment obscurity is a part of your approach, you are relying on it. And AFAIK that's considered to be dangerous.

[theckman]

@hernandev I didn't say that it was applicable here, I think the standard should be followed. I was merely stating that obscurity can add value as a layer of your security protections. A layer meaning that it's contributing to a larger solution. It cannot be the only solution.

AES-GCM, or even encryption in general, is a good example. Isn't it just obscurity? Does it contribute to the security of your data?

[jin-liu]

Thanks for the valuable feedback. Firebase team is working to publish the modified scrypt implementation on github repo. In the meantime, please file support ticket to Firebase, and the document will be shared with you.

[hernandev]

@jin-liu that's absolutely great news! Firebase only wins by being transparent.

Congratulations on your take on this matter.

[kmcnellis]

We just open sourced Firebase's version so that you can do your own password verification. Check it out at github.com/firebase/scrypt

[aarti]

Thank you!

[jbrantly]

While this is a huge step in the right direction, I still feel that it's unfortunate Firebase didn't go with a standard implementation here. It would still be difficult to migrate to other auth solutions since you would need to implement this custom algorithm, assuming the solution even allows that. Going with almost any of the many standard implementations (see the hash-algo documentation for the CLI import command) would have allowed much easier lift-and-shift of authentication data into and out of Firebase.

In any case, 👍 for making moves in the right direction, but wanted to provide my feedback to your product team as a potential customer. Thanks!

[katowulf]

@jbrantly I hear you loud and clear. Simple is always preferably when it can be achieved. But we have privacy policies and security standards like every other org, and the standard implementation didn't meet our expectations. Development at scale is all about making the right tradeoffs and we're always listening to your feedback to make sure we make the right ones. Thanks for chiming in with this. It really is valuable.