What are your default 'safe' meaning in software security?

I'm bad at english any word correction welcome

I never build a well-known app that maybe get some DDOS attack or XSS. This is why I'm asking this kind of question to folks here 😄 I never feels secure about my app.

Lest talk this on web platform, but I welcome any 'safe' opinion around other platform.

For simplicity lets build Login and Register app only, nothing special.

I'll consider that app safe when I do this:

• Hash password
• Using HTTPS
• Using JWT for auth and store that on localStorage/or cookies
• Sanitize my input

That's it from me. Whats yours? Do you had any tips for me? 😃

Comments

[rhymes]

Hi Manda,

I never feels secure about my app

that's a great place to start, me neither!

A good way to deal with auth is not to build the auth app from zero at all :) In the sense that if you don't have to deal manually with authentication then you probably have safer best practices put in place by a trusted framework or a third party provider if you use an external service.

That doesn't mean you still don't have have to know how the whole things works but maybe building it from zero it's not a good idea, unless your business is to provide authentication.

You can also consider adding 2FA.

Another great way to increase the odds at safety is not to have a server to manage at all. Using PaaS or FaaS cloud computing you avoid dealing with patches and software upgrade yourself.

Going back to your example, I think it's a decent start except for JWT inside the local storage. The local storage is visible to every script running on your browser, regardless of which apps stored it in the first place, which means that a potential attacker can retrieve data. That doesn't mean "don't use local storage ever", just don't put sensitive data in it, like an authentication token. You can use it to store a username or something else for example. A http only cookie is a safer bet.

Another trick you could implement is to integrate the Have I been pwned API in your login/registration process, so that you can guard against previously breached passwords.

Cross site scripting is also another thing to keep in mind as a web developer and you can mitigate that by using frameworks with CSRF protection and by using content security policy headers.

Avoiding known vulnerabilities by integrating auditing tools in your build process it's also another thing you might want to consider. They are not fool proof but at least they catch known vulnerabilities before deployment.

A couple of resources:

• OWASP 2017 Top 10 security risks explained
• Mozilla Observatory which can scan your website and give you ideas for improvement.

[Manda Putra]

Hi great explanation thanks :) Just know that pwned had API, will use that to check the password.

I'm start using localStorage because all of tutorials around this world are using localStorage for storing JWT, thats good start for newb like me... but today yeah as you said the safer bet is using cookies. Thanks ! :)

[Ryan Smith]

Most times, the human is the weakest link when it comes to security. I recommend the following to secure yourself and the services you use. Having a secure codebase won't do much if an attacker can bypass that by attacking your passwords.

• Use secure admin passwords (with numbers and symbols) for any third-party services used for the app.
• Do regular resets for admin passwords.
• Don't store passwords on a sticky note or a text file.
• Enable 2FA for any third-party services used for the app.
• Do not reuse the same password for every service.
• Don't click links in sketchy emails (phishing). For questionable emails, go directly to that website and log in instead of clicking the link.

Some for code:

• Hashed and salted passwords.
• Using prepared statements in SQL can help prevent against SQL injection.
• Separate your environment variables from your code in a .env file, outside of your code. Do not put API keys or database connection information directly in your code. If it were ever open sourced, that would be visible to everyone.
  • I have also seen cases where credentials were in a .js file (intended to run for Node.js) and stored in a folder that was hosted on a web server. Since .js files should be viewable/runnable from a browser you could navigate to website.com/index.js and the credentials were visible.
• For JWTs, you need a method to expire them. Otherwise, an attacker can get a user's JWT from local storage and make requests on their behalf.
• Always confirm a user's permissions in server-side code, not client-side. A user should not be able to write &admin=true in the URL and gain access to an area they should not have access too.

[Manda Putra]

Hi ryan thanks for advice. Been trying new Sodium hash format for now.

I use .env files but that same folder on server as my code is that okay?

I heard backthen some of Laravel folks with weak security server leaked .env files on google search

[Max Ong Zong Bao]

I might consider including two-factor authentication that sends you a challenge email or SMS to enter for the user to register and confirms their identity.

The JWT wise I might reduce the token duration to a fix duration and check for expired tokens with options to refresh using unexpired token.

Besides that, I might consider to just use Auth0 or Okta technology to implement the following features.