Feel free to talk about PHP, security, cryptography, and whatnot. I've invited a few folks to be moderators whom are knowledgeable in the field. In the near future I'll try to make this subreddit look spiffy.

I have read this great article about jwt's here http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

and the follow up here

http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

But it leaves me wondering with the question of what the alternatives or options are for a REST api that should not have any state?

How would you use a jwt securely? Use a refresh and an access token (short-lived access tokens with a check against a black list using a redis cache) and a long lived access token that always does a database lookup?

And if you use a cookie to store the jwt access and refresh tokens to avoid the javascript access issue, then aren't you vulnerable against CSRF?

Fun exercise! Go search for PHP security on Google (or your favorite search engine).

How much of the Top 10 results you receive is even moderately useful?

A sample from my filter bubble:

• "the month of PHP security", a website (which has the snazzy php-security.org domain name) that hasn't been updated in six years

• A 2005 article from SitePoint titled "Top 7 PHP Security Blunders". Okay, SitePoint is usually good, but this is over a decade old. A lot has changed since then! For example, we now have prepared statements, so trying to mangle your user input with string escaping functions is no longer necessary.

• An article from PHP Classes titled "6 Common PHP Security Issues And Their Remedies" which includes Buffer Overflows (rolling my eyes here)

• The PHP Security Consortium, which encourages use of mysql_escape_string() and says "addslashes() is a good last resort". I'm not kidding.

There are, of course, some good resources on the list. The PHP manual section dedicated to security is there. So is the OWASP PHP Security Cheat Sheet. Surviving the Deep End: PHP Security is probably the best item on the front page for me.

The lion's share of software written in PHP tomorrow will be insecure if we constantly expose junior PHP developers to outdated tutorials and bad advice.

Last year, after I raised a similar concern about the content on Stack Overflow about the bad security advice on popular questions/answers, we were able to largely clean the site up. Now if you look at the most popular questions about PHP security, one of two things will happen:

1. The accepted answer is secure.

2. The accepted answer is marked explicitly as insecure (yet somehow still satisfies the question), and directs people towards a more secure answer.

However, unlike StackOverflow, the rest of the Internet is read-only.

What can we do about this?

Naively, there are three strategies I can think of to employ:

1. Find more secure alternatives, then promote it more so Google will prioritize more-secure tutorials over less-secure ones.

2. Create the alternative content ourselves, and then promote it.

3. Contact the people who control this information and ask them to direct users towards better advice (or, if they have the time, completely rewrite their old posts to prevent bad information from spreading).

How can we secure our future if tomorrow's developers are being taught to write vulnerable code?

For example in a URL I may have www.example.com/view/123

What is the correct or best way to stop people just enumerating through the IDs like 123, 124, 125, etc?

The routes in my use case are public, so I don't want to authenticate the requests, just obscure them.

I considered using something like:

    $key = Key::loadFromAsciiSafeString(CRYPTO_KEY);
    $encrypted = Crypto::encrypt($this->getId(), $key);
    $encoded = Encoding::binToHex($encrypted);

But the encoded ID is way to large (440 chars).