CICiPHPerCoder·Jan 17, 2018
> But that doesn't mean you should be send and storing password hashes to the server, even if generated by PHP.
There is prior work in this genre. Something like SPAKE2-EE might be worth looking into here. https://github.com/jedisct1/spake2-ee
> It doesn't mean you should be using the session cookie alone as a bearer token to access a session.
Well, maybe.
A random ID that just tells PHP where to look for the session data, with all the data persisted server-side, is secure as long as it's transferred over HTTPS. Most frameworks/libraries abstract the implementation details away, but generally:
<?php
use ParagonIE\ConstantTime\Base32;
$random = Base32::encode(random_bytes(32));
This value will be unpredictable and doesn't require an HMAC to ensure this property. The only time the HMAC adds value is if you're using the user's compute
Read the rest
r as a data mule for the entirety of session state rather than "look up this identifier in a database".
In those use-cases, you enter the usual JWT abuse territory, as outlined here: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...
In this genre, we're working on PAST (although this is probably going to be renamed before it's finalized) to solve the cryptography flaws baked into the JWT standards (collectively, JOSE): https://github.com/paragonie/past
That doesn't solve the "replay attack" issue (which may be what you were referring to with bearer tokens).
> OH AND YOU SHOULD ALSO BE USING A PRIVATE KEY PER USER TO ENCRYPT DATA AT REST ON YOUR DATABASE, AND STORE THIS KEY IN THE DB MULTIPLE TIMES - EACH ONE ENCRYPTED BY THE USER'S DEVICE KEY.
I'm not entirely sure what you're getting at here. If I needed to share a key across devices, I'd either use Diffie-Hellman or Shamir Secret Sharing to accomplish the task (depending on use-case and threat model).
Perhaps there's a lot of implementation detail that's not being discussed here that I'm missing and what you're saying is a conservative local maximum, but it stuck out a tad bit.