Everyone wants to sell things online. eCommerce websites are popping up left right and center. But where do you start?

Our boss/clients have an idea of what they want, but we as software developers are a key stakeholder when it comes to building eCommerce systems. After all, we’re both building the application and using it. There are multiple paths we can go down, but a common challenge that we all face is security; Protecting the customers data!

During the talk, we’ll look at some real world examples and security titbits in how we can protect the application, with Rob drawing on over 9 years of eCommerce experience.

Comments

Please login to leave a comment

Rated 4

Lucia Velasco at 20:54 on 10 Jul 2019

I love starting with a practical scenario! And I love being involved in the feature/product lifecycle from the start.
I adore gratuitous shaming of insecure companies.
"Can I have those credentials?" [1 new email] :scream:
Mr Hacker is great.
I liked that you interacted with the audience and prev speaker!
The code text could have been a bit bigger (and I hope no one's red/green colour blind!).
Unpasteable passwords. Bane of my life.
I really liked that you mentioned environment variables!
Really great talk. I appreciate the practical, doable advice. I would have liked more scary stories, but I'm a sucker for schadenfreude! Thank you!

Rated 5

Andy Gale at 20:58 on 10 Jul 2019

Your secret is not safe. Brilliant talk perfectly complimenting the previous talk. Learnt a lot. Great relaxed talking style. Really impressed and would love to hear from him again.

Rated 4

Sam Rogers at 21:02 on 10 Jul 2019

Excellent talk on what can be done as first steps, a more in-depth version would be really interesting.

Crowd interaction was at just the right level, that was really good and good callbacks to earlier parts of the talk.

Would like to see a collection of the recommended tools on the final slide so that. Definitely knew the material and the talk, can see this from being able to find some of the material with a quick flick back through the slides.

Rated 4

Ed Martin at 21:02 on 10 Jul 2019

Good and informative thanks; covered the basics well

Rated 4

Craig Francis at 00:14 on 11 Jul 2019

A good talk, covering a load of things for people to look at, and should give everyone at least one thing to think about and improve in their own systems.

Just some notes/thoughts.

While some companies find GDPR a headache, as noted in the intro, I’d phrase it more positively, it’s a great bit of legislation, and reminds companies how they should be looking after their customers data to begin with.

FTPS/SFTP are different but similar (first is FTP with TLS/SSL, the second uses a form of SSH), and both only encrypt/decrypt data over the network. I read one of your slides as implying that it was encrypted on the server (with the encrypt step being on the upload side, and decrypt being on the download side).

OAuth2 is very useful, and I completely agree that you should use standards when possible, but when it comes to API’s (server to server comms only), it’s not always a great choice, as it’s more designed for a person to share their data from service 1 to service 2. I think you should focus more of the HMAC/signature with nonce (which was good to see).

Very good to see the complaints about self signed certificates, especially as programming languages like PHP stop accepting them by default (they can be made to work, with pinning, but you have to be careful).

CSRF won’t stop multiple attempts... can’t remember why I wrote this note, I may have misheard you.

I wouldn’t use FILTER_SANITIZE_STRING on a password field, as it can remove characters.

Good to see password_verify() in use, maybe worth adding a comment about password_needs_rehash()?

ReCapture, that could work, I’m just not sure I’d like Google seeing the password being entered, it can also cause issues for anyone with disabilities, or customers getting annoyed at the challenges (especially when they are using incognito mode)... maybe look at throttling connections first (based on source IP address), or only on failed initial login attempt.

And as an extra fun step, after hashing, and ONLY after hashing (the most important bit, which you covered well), you could add encryption as well... if your database is on a separate server, this makes a compromise in the DB better protected, where customers with bad passwords won’t be found early (you may have correctly used a slow hash, but pa55word will be found quickly), and if you use sodium_crypto_aead_chacha20poly1305_ietf_encrypt() it takes “associated data”, where I’d suggest using the users ID, so that the encrypted value cannot be used with any other account.

Rated 5

Piers Hobson at 07:25 on 11 Jul 2019

Touched on a number of security issues to give a good overview, with anecdotes from experience. Good slides.