2

I see this saying a lot and agree that you should leave certain things to the tried and true methods, but am unsure to what extent. Does it just mean don't make your own crypto algorithm? I created a simple create user set up for a client app - server in c#. user sends username, password through WPF to a WebAPI that creates an entry in a database with the username, generates and stores a salt, stores number of iterations (10,000). It then uses .net pbkdf2 to create a hash and store it.

Is this rolling your own security?

BottheBob
  • 23
  • 4
  • Related: [Why shouldn't we roll our own?](https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own) – Arminius Aug 27 '17 at 01:51
  • If you think the linked post is not a duplicate you might want to emphasize that you're asking about your specific case and not what's bad about "rolling your own" in general. – Arminius Aug 27 '17 at 02:10

1 Answers1

5

Quoting Bruce Schneier:

Anyone can design a cipher that he himself cannot break. This is why you should uniformly distrust amateur cryptography, and why you should only use published algorithms that have withstood broad cryptanalysis. All cryptographers know this, but non-cryptographers do not. And this is why we repeatedly see bad amateur cryptography in fielded systems.

'Rolling your own crypto' means you designing a new algorithm that you then proceed to use without either:

  • Auditing it, or worse

  • Publishing it at all. That is - keeping the algorithm private.

By implementing a known and trusted process or algorithm like pbkdf2, you have some level of guarantee that it has been audited and will not keel over and die the minute someone prods the algorithm itself. By using a widely accepted standard, you have some level of assurance that the algorithm is not going to be flawed and you only need to ensure that your implementation is secure. This is not rolling your own crypto. This is you implementing it and if your implementation is correct and you follow the guidelines, you're golden.

Further reading that might help: Schneier on the subject

thel3l
  • 3,394
  • 11
  • 24