You're right to worry. A common advice is to never ever draft your own authentication mechanism, because you will get it wrong. Pick an existing one; understand how it works; use it in your project.
This works for cryptography too. Don't invent your own patterns. I'm not exactly sure what you mean by “password matched with regex and hashed with salt,” for instance, but it sounds wrong. You're not supposed to use regular expressions when checking for passwords, and you're not supposed to do anything with the password before hashing it. Use something such as PBKDF2, which would handle all the hashing and salting for you, transparently (alternatives do exist).
Even better, don't even bother validating passwords at all. Even if you use PBKDF2—which would give strong guarantees that if your database leaks, a hacker couldn't find the original passwords—it would provide no protection if the server itself is compromised. If a hacker has root access to your server, he can just grab the plain passwords from the HTTP POST to the login page. As easy as that. Instead, delegate authentication to a third party, such as Google or Facebook through OpenID or OAuth 2.0. It works this way:
- The person arrives on your website and wants to login.
- He gets redirected to Google login page and does all the stuff there. It's a black box for you: it can be as simple as clicking on his name if he's already logged in, or as complicated as entering the password and confirming his identity with a smartphone—something you'll pay for with every SMS sent if you implement it on your own.
- Google redirects the user back to your site, telling you that the login was successful.
Now, even if your servers are compromised, you can be sure that you won't need to disclose to your users that a hacker got all their passwords. And with many libraries for many different languages and ecosystems, it is relatively easy to integrate OpenID or OAuth 2.0 in your web app.
To address the comment below:
And what if you do not like or trust Google or Facebook?
While Google and Facebook providers are the most popular, they are far from being the only providers there. A more complete list shows that even those who mistrust every US-based provider can find an option, such as VK and Yandex for Russian-based websites.
And also, what if only users that are authorized by you may login?
Both OpenID and OAuth tell you only that a given user was authenticated and has a specific set of metadata (email address, avatar, etc.) and a specific set of roles. Now, it belongs to your application to decide what to do with this information. You may log the person in. Or you may decide that only the users with specific OpenID IDs can login, and every other person should be rejected.
For instance, I'm using Google's OAuth to handle authentication for sensitive web applications, such as the one which enables/disables the alarm in my house. It wouldn't be very practical if anyone with a Google account could disable the alarm, so the application has a list of hardcoded IDs (mine and the IDs for my family members). If the ID matches, you can see the web app. If it doesn't—sorry, HTTP 403.
Those IDs are what the application receives back from Google. In other words, Google tells, literally, “the person authenticated; his ID is 5900731...685, his email address is firstname.lastname@example.org, and, BTW, here's his full name and avatar.” The person's full name and other elements are not interesting from the perspective of security: what interests you is the ID, or more precisely the pair (identity provider, ID), to avoid conflicting IDs if you use multiple providers. This pair becomes de facto the identifier of the user for your site, given that the same person can have naturally more than one ID (for instance if he logs in sometimes through Google, and other times through LinkedIn).
Based on this ID, you can take all sorts of decisions, like, for instance, showing the personal space of the user. Or, in a case of a system which, by design, is limited to a very narrow set of users, such as a home automation system, or a corporate build server, you can simply hardcode those IDs to allow only those specific users to access the application.
If somebody creates a Google account and logins to your site with it, his ID will not be among the whitelisted ones. Therefore, he won't be allowed to get in.