And I'm also wondering about going back to university: Is it difficult to get into a good ML PhD program if you've been in the industry for some years?

It is not impossible to work at these labs as an engineer without a PhD, but I don't have a deep understanding of these roles.

Once I had finished that, Cullen's "Matrices and linear transformations"[2] was really helpful too. But I wouldn't do Cullen if you're still, as I was, floundering with the concepts of why you're doing this in the first place. It's great once you have those concepts down.

[1]: https://www.amazon.com/All-Mathematics-You-Missed-Graduate/d...

[2]: http://store.doverpublications.com/0486663280.html

Now let's see what happens after two steps. If the system started out in state i, what's the probability that after two steps it will end up in state k? Well, it's the sum over all possible paths. In other words, the sum of probabilities of i->j->k for all possible j. In other words, the sum of p_{ij} times p_{jk} for j from 1 to N. But that's exactly the definition of multiplying a matrix by itself.

Now it should be easy to understand that whenever you have matrices that represent transformations of some object, composing transformations will correspond to multiplying matrices.

[1]: https://www.youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2x...

http://math.stackexchange.com/questions/31725/intuition-behi...

http://linear.axler.net/

http://linear.axler.net/LinearAbridged.html

In PHP:

    $storeMe = password_hash($plaintext, PASSWORD_DEFAULT);
    if (password_verify($plaintext, $storeMe)) {
        // Logged in
    }

See: https://paragonie.com/blog/2016/02/how-safely-store-password...

EDIT - CANNOT REPLY:

  > One major failure of this article:
  >
  > You should generate a random salt for each user and store it alongside the user
  > record in the DB.

  > I completely disagree. This implies that my DB ORM handles password stuff,
  > which doesn't make sense.

You should generate a random salt for each user and store it alongside the user record in the DB.

This result of bcrypt:

   $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
    |/ \| \____________________/\_____________________________/
    |   |        salt                      hash
    |  cost 
    |
 algorithm,
  version

Most people seem to think, and myself included when I was new-to-it, that storing all those things together would compromise the security. The point of the hash is that it is impossible (almost) to get to the hash without the user's password, and there is no way to get to the password with the entire string you posted.

So somebody with resources and motive could still brute-force that string. It seems that storing the salt somewhere else would add a comparable amount of security as the salt itself. It seems prudent along the lines of "don't put all your eggs in one basket."

Yes. Because if you had two users with the password 'dadada' they would hash to the same value

Now 1234:dadada hashes differently then 1326:dadada hence preventing the use of a prehashed table (you could go through all salts for common passwords, but it's usually a bit long as well)

You do manage it yourself. Password hashing library doesn't access your database, it produces a string that you store, which includes salt and password hash.

In our case, we use an immutable attribute of each user as their hash

What? You really need to talk to security-competent people.

I assume you mean "as their salt". And even then, why the half-measure? Just laziness? Sure, a guessable/computable salt is better than no salt, but it's not nearly as good as a random salt.

Yes, thanks for clarifying what I meant to type.

why the half-measure? Just laziness? Sure, a guessable/computable salt is better than no salt, but it's not nearly as good as a random salt.

But isn't the salt essentially safe to make public anyway? That being the case, how does it matter what value you use, so long as it differs between users?

If there's a reason for it (in most cases, there is none), some trade offs are possible, e.g.:

Salt is a large random string unique per user, not per password.

Given two hashes of passwords for the same user it reveals whether passwords are the same.

Salt is a small random string or some predictable value.

Attackers can precompute guesses and then look them up.

If you use some immutable identifier per user as salt, both of these attacks are possible. Is there a reason for this? Since you already store password hash in your database, I'm 100% certain that it's not, you can generate large random salt per each password hash and store it.

As for "safe to make public": there are many things in crypto called "public" where "public" doesn't mean that the whole world is free to get it, but instead means an opposite of "private", or, as I like to call them, "non-secret". Yes, salt can be made public, but shouldn't (unless there's a reason for it — like in a kind of client-side crypto where server stores salt and sends it to clients) to avoid precomputation.

Of course it's per user.

But "large" makes some sense. My current implementation has maybe 20-22 bits of uniqueness in the salt, certainly less than 16 bytes.

I don't think 16 bytes is necessary even as insurance against the future. Rainbow tables are still expensive to build.

On the other hand, maybe to build just a small table addressing the stupidest passwords ("password","12345678",etc.) it's worth making it more difficult.

What I meant is that it shouldn't be per user, it should be per password. If a user changes his password, he should get a new salt.

The birthday problem comes into play here.

If you have 22 bits of entropy in your salt, after 2048 users (2^11) you will find two with the same salt, with 50% probability. If they also use the same password, this makes attacking your users much easier.

Don't make it easy for attackers. Use 16 bytes from a CSPRNG. Better yet: Use a password hashing library that takes care of this for you.

If you use a 128-bit (16-byte) salt, you have a 50% chance of a collision after 2^64 passwords.

Good look at the issue here: http://security.stackexchange.com/questions/41617/do-salts-h...

Otherwise, that claim is false.

I completely disagree. This implies that my DB ORM handles password stuff, which doesn't make sense.

Python 3 example:

Syntax: hashlib.pbkdf2_hmac(hash_name, password, salt, iterations, dklen=None)

Example:

>>> dk = hashlib.pbkdf2_hmac('sha256', b'password', b'salt', 100000)

>>> binascii.hexlify(dk)

b'0394a2ede332c9a13eb82e9b24631604c31df978b4e2f0fbd2c549944f9d79a5'

Extremely simple and safe to use. Trivial to store and save/retrieve the salt from DB.

1) You need to store the salt alongside the password.

2) If you want to futureproof the stretching factor (e.g. change from 100000 to 1000000), you need to store that alongside the password hash as well.

3) If you want to futureproof the hashing algorithm, you need to store that alongside the password hash.

The value of the *crypt solutions is that they store the input parameters as part of the stored secret. So you can make adjustments later on without invalidating existing stored passwords, or having to resort to annoying "double-hashes" to migrate to a new approach.

I don't understand your comment about the ORM needing to handle passwords. It's a simple fetch of a field from the DB, which you then pass as an input to your password validator. How is that any harder than fetching a salt and a hash and passing those to your validator?

It's mind-boggling how many well-known companies stored passwords badly.