This article is a first in series of explanations to all claims done by our former colleague that claimed he found numerous security and performance issues in our project shortly after joining our team.
You can find the preface here.
Lets have a look at the first claim:
I guess that we transfer data from GUI to the API server probably with HTTPS , but this is not enough. Because a person can easily get a SSL certificate with DNS spoofing and listen to the packages. So the first thing is , We are sending our password for login or any other transaction as a plain text and then we will only encrypt it on DB. We must also encrypt the passwords on the client-side with another salt or another type of encryption when we want to send a request like LOGIN function. (recommend different salt for different customers)
First question that should come to our minds is; why would everyone including huge international companies like Microsoft, Google, Mozilla and Intel invest so much time and money into developing support for HTTPS and SSL/TLS into basically all web browsers, improving SSL/TLS protocols with enhancements, bug and performance fixes, forming certification authorities and creating selling points of certificates for companies and individuals when based on this description it seems to be totally trivial to overcome the whole protection of SSL/TLS and certificate based security???
How would you justify in your company buying a $199 EV SSL certificate for just one site for one year if this would be true?
Let's first start with how SSL certificates are obtained. Most certification authorities (from now on called CAs) require you to prove your personal identity to get basic certificates. This can be accomplished e.g. by validating and assigning your e-mail address to your CA account. For so called EV (Extended validation) certificates - that give you this well known "green lock" in the browser's URL bar, you need to undergo a more strict procedure in addition to the personal verification by e.g. faxing/photocopying a company certificate, address and/or validating your relationship by making a phone call from a phone-number associated with your company in public registry, or receiving a validation code using postal service delivered to your company postal address. This guarantees that nobody else without access to your e-mail, private company post box, office or phone device can validate him/her-self as company representative to gain EV validation for your company at the CA.
Now that you have validated your person or company you need to actually prove you own the domain you'd like to get certificate for. Of course e.g. google.com domain is no more owned by Google company (it's now called Alphabet) so when you are validated as a company you are eligible to request any domain certificate not only one that matches your company name.
For this purpose you have to alter the public DNS records or your HTTP server settings to return expected response to your CA request. E.g. you may be asked by your CA to set up a special DNS record with name d24ecd160f4443b5ba55374b15516fc3.yourdomain.com that points to their server or return specific TXT response; or that by visiting URL http://yourdomain.com/d24ecd160f4443b5ba55374b15516fc3.txt you present a content from a text file delivered to your previously validated e-mail address by the CA.
This way only person that has access to the DNS management of your domain and a web server that your DNS records points to, is able to successfully validate certificate request by the CA.
As you can see without extensive social engineering, wiretapping, breaking into someone offices or post box at the right time, hacking your DNS provider and server hosting it is quite hard to request a certificate to arbitrary domain name on someones behalf.
Let's be honest and say that in the past, there were some incidents where due to human errors and heavy social engineering some less known, smaller CAs erroneously issued certificates for different company domains like Google. This can happen but it was soon discovered and corrected. In this case certificates must be invalidated (revoked) and new ones for affected sites re-issued. For this purpose each CA exposes so called Certificate Revocation List (CRL). These lists are checked by your browser by each time an access to certificate protected site is made, to disallow access to sites that are compromised and served with certificate already revoked by the CA.
So now when we've explained how it is hard (not impossible) to fake a certificate let's explore options how this actually can be done without any user even noticing!
And here everything boils down to trust. The easiest way to convince someone he's accessing a perfectly valid and secure certificate protected site is by lying to him. What does that mean you ask?
The whole sense of safety is a result of you relying on your browser to tell you if the site you are visiting is fine or there's something fishy going on by looking at the browser error displayed when you visit misconfigured or fake site.
Rule number one: Use only web browser downloaded from verified source
Never ever download a web browser from untrusted sources (download sites, warez sites, custom browser builds on GitHub, etc.). It may be tempting to have an "Un-Googled Chromium" - perfect browser based on Chromium with Google spyware removed (TM). The only source of these browser builds are random people on the internet. You may get a browser that was built from official GitHub repo with Google stuff removed but sneakily one CA certificate added that is under control of an attacker. Results may be disastrous. By having an attacker controlled CA certificate bundled into your browser one can, in addition to DNS spoofing redirect you to an attacker controlled server hosting an exact copy of Gmail login page. Just type in the credentials and they will be sent to the attacker's server without you even noticing!
Some browsers do not come with CA certificates bundled and instead rely on the operating system CA certificate store. There is also a risk associated with it because the code in the source code of this untrusted browser download may have been modified to use internal CA certificate bundled in it.
In case of browsers like Internet Explorer running on Windows without antivirus combined with untrusted applications from unverified sources can result in system infection that imports own CA certificates into Windows/Linux CA store. All browsers using these store would then be compromised even if the browser itself comes from verified vendor's site.
Rule number two: Run antivirus combined with software from trusted sources
Do your job and verify downloaded file's hash with the one the vendor provides. Most of them do now!
An alternative would be to run regular browser in a sandbox or Virtual Machine and only use trusted browser on your main operating system to access important sites (banking, mails, company portals, social media, etc.)
Some attacks are also possible on insecure networks, especially public WiFi. Here the claim about DNS spoofing comes to effect. Although without compromising your operating system and/or web browser it's hard to fake certificates, what can actually happen is that your request to gmail.com will be handled by the DNS server under attacker's control and you will be redirected to similarly looking gmial.com domain with valid certificate. It is common to do this kind of tricks as user's don't usually check what they typed in after the page they receive looks what they expect it usually does. Similar typo-based domains are registered and pretend to be their original counterparts so always beware on untrusted networks. Use your own DNS settings paired with DNSSEC or DNS over HTTPS or use VPN to browse the internet. Or if you have such option, do not connect to unknown networks and use cellular network instead.
Rule number three: Never trust unknown networks and use VPN if you need to
Hope you enjoyed this post and thank you for reading!
In the next part we can have a look at why may accessing even self-signed certificate sites be secure in some cases and what it means to establish an SSL/TLS session with remote host.
Top comments (4)
Hi,
thank you for your feedback.
Let me tell you (certainly almost) nobody uses passwords encrypted on the frontend. Not Google, not Microsoft, not your Bank.
And there is a reason for this.
Even if you encrypt a password and send it as a hash instead of plaintext, you need to accept username/hash combination on the backend. The Man-In-The-Middle attacker can take your hash instead and make authentication attempt the same way as he would do with plaintext password. You added no security.
You could try to solve this problem by encrypting your password on the frontend with random salt that the MITM does not know, generated for each login attempt. But for this you have to first send the user the random salt to the login form which MITM can read anyway so he has the salt and a hash - no added security...
All this has already been solved. It's called TLS (previously SSL) that is the lower part of the HTTPS protocol that does this during TLS session establishment where the very first part is to securely agree between the client and the server on random pre-shared key in a way, that MITM is not able to guess it - using Diffie-Hellman key exchange.
In addition random unique key is generated from server's private key on each session as part of Perfect Forward Secrecy to avoid possibility to decrypt all sessions derived from one private key in case this one is compromised. That means if you manage to get hold of the server's random private key - you are only able to decrypt one session but nothing else (sessions started before or after or with different clients have their own random keys).
This is our plaintext encryption "salt" that guarantees the password inside a HTTPS protocol login call is each time encrypted differently without the MITM attacker to be able to compromise it, and even if he does it's invalid in any other started session. The benefit is you have to do nothing at the application level. This is baked into another ISO/OSI layer and is fully transparent to higher protocols like L7 HTTP.
So please, do not try to reinvent the wheel!
And yes, our site has strict policy regarding HTTPS. We implement HSTS, CSP, we do not support HTTP connections at all.
Please stop being rude.
I tried to explain to you you don't ever need to hash passwords or any sensitive data if you're using lower level security which does secure shared secret negotiation followed by encryption of payload in transit.
If you don't care why Google sends cleartext passwords you're the one that's missing something.
Please, go and study that topic to understand it.