0

Our company have 10+ private websites and 20+ person and need to open a different one automatic when the developers are testing some functional. We do not want anyone outside the company to view the content of the private websites.The websites is access with ip and port.Those websites have public ip, can be access from any place.

So there is two options:

  • We can open http websites and use a http basic auth with a fixed username and password to login. When someone leave the company the password will change.
  • We can create a self sign CA and a client certification , and use that ca to sign a https server certification to the websites, and the websites need the client certification to view. We will continue using the fixed username and password and http basic auth in the https websites.

Will option 2 safer than option 1? Or it is just a illusion of safer because of https?

Is there any bigger safe problem in the option2?

additions

  • We put the server of websites in big datacenter with public ip to access data faster, put the server internally will make it access the data too slow to work. So the websites will access from public ip, I do not know any way to prevent it.

  • Using vpn can make the websites easy to not work when the vpn server itself dead. And it make the end user difficult to use the websites, as we already use vpn to do some jobs, two vpns is impossible in some operation system. (like android/ios)

  • We use the fixed username and password to prevent the left person have the access to the private website. They are fixed , so we can use less time to manage it.

  • If the websites are not intended to be accessed by the public, why are they on public IPs? Why are they not on a server that is only reachable internally? – MechMK1 Oct 22 at 16:06
  • @MechMK1 Because the websites needs to access the data fast enough to work. Put the websites in server internally will make it access the data too slow to work.As we do not have an internally connect to the data. – bronze man Oct 22 at 16:15
  • So if I assume it correctly, your server is somewhere in a datacenter (where speed is high) and not at your office, where speed is presumably low? – MechMK1 Oct 22 at 16:50
  • @MechMK1 yes. You are correct. Put the website in server in office will make it access the data too slow. – bronze man Oct 23 at 1:00
1

Simplification

Neither option is remotely secure. But you present those as THE options, so I'll address them first, then present you an option 3.

Security: Technical

Given your two options, neither is technically superior. The addition of SSL/TLS would only be security theater.

In regards to your public internet exposure, neither option provides reduction of attack surface or hardens your underlying systems from attack. An attacker accessing your sites from the public internet would be able to simply accept any self-signed certificate if you have one, and would not worry about it if you do not.

In regards to your internal exposure, SSL/TLS is primarily intended to mitigate man-in-the-middle attacks (not its only use, but primary). Since this is internal and all persons log in using shared user/pass, there is minimal gain for a potential internal attacker. If the internal attacker has access to the shared user/pass, the attacker can generate any traffic any other user would generate.

Note: I yield a TINY amount of extra security with the SSL/TLS (at least our attacker can't see what others are doing). Given the described scenario, I evaluate the worth of that tiny sliver to be otherwise not worth mentioning.

Security: Procedural

In terms of process, leaving SSL/TLS out is actually more secure. Given the above technical lack of additional security, you've now added management of a security resource to the mix.

Unnecessary complexity is an enemy of security.

Security: Human Factor

In terms of process, leaving out self-signed certs is more secure.

Consider what you will be training users to do: adopt a workflow where self-signed certs are to be accepted. You want users to always, ALWAYS seek guidance when they receive a browser warning regarding certificates - be that from the company's help desk or from the site's help desk.

Regardless of cert or no cert, you say that you will change the password whenever someone leaves the company. This requires all users every time to adopt a new password. If your turnover is high, users will inevitably start writing down the current password.

Do not train your users into bad patterns.

If ONLY the two options are options...

Leave out the SSL/TLS. The described scenario is severely security deficient, and adding security theater only provides a false sense of doing something.

Changing perspective...

So Option #3, as promised, requires you, the asker, to adopt a security-minded approach. Big factors I see as problematic in the situation you describe:

Technical Gap: Adding SSL/TLS does not necessarily add security (or at least, any amount worth mentioning). The reasoning behind shared user/pass is faulty. This indicates the overall system was designed by someone lacking technical cybersecurity knowledge and understanding.

Attack Surface: Having these internally used sites publicly available is a massive attack surface. If they are to be used only internally, they should be accessible only internally.

Shared credentials: While there are certainly some edge cases where I'd entertain the prospect of shared credentials, it is a bad design pattern. If a person leaves your company, you have to change a password -- it does not matter if it is their personal password or if it is the shared password. The risk of overlooking this step is identical for both shared and individual credentials.

Taking the given scenario, the following corrective actions would help reduce risks (listed in order of greatest value to least value):

  • Any and all technical staff should seek cybersecurity training. This should include engineers, systems administrators (OS, DB, network, etc...), architects, developers/coders, even help desk. All users should also receive basic security training (which should be broader in scope than cybersecurity training, but shallower in depth).
  • Use an edge firewall to block access to the sites IPs from outside. Most modems/bridges have a basic firewall built in; while a dedicated appliance that can create external, internal, and DMZ zones would be better, using the existing built-in firewall is a step in the right direction.
  • As soon as feasible, retool the system to use individual credentials. Realize that an account has to be updated whenever a person leaves the company anyways -- choose the option that least inconveniences other users.
  • If you've implemented individual credentials, SSL/TLS finally offers a reasonable addition of security. Self-signed certs are not HORRIBLE, but given the low costs of getting a proper chained cert from a public CA, a public CA vs a self-signed cert would be the superior option of the two. If you MUST use self-signed certificates, ensure these are pre-bundled when a new system is deployed; this prevents training users to ignore certificate warnings.
  • Thanks, As those websites need the client certification, the user can not simple ignore the certificate warnings.He need install a client certification to view that website. – bronze man Oct 23 at 1:10
  • @bronzeman If you're using client certs, then why are you bothering with user/pass at all? The password should be on the user's private key. But how are you managing all your user's public keys on the servers? Do you have a properly configured PKI? – LRWerewolf Oct 23 at 8:03
  • There is one ca, a lot of server certifications for different ip, and one client certification for all users, it can not stop the leaved person to view the websites, so there is one password that will change to stop the leaved person to view the websites. – bronze man Oct 23 at 11:51
  • @bronzeman Based on your most recent comment, I cannot stress enough the importance of the first suggestion of my offered Option 3. The system you seem to describe, as I reconstruct it in my head, is unrecoverably insecure and would need a near-total retooling to add security to it. – LRWerewolf Oct 24 at 17:30
  • Thanks, you are right. There is a lot of place to implement. I also think use public CA may be less secure than client certifications and self-signed CA, as the big government can do bad thing without everyone notice. – bronze man Oct 25 at 1:10
2

I'm coming from the assumption that you don't leave any backdoor open in either of the methods, and choose high-entropy passwords for Basic Auth. In that case, the biggest difference between the methods is that HTTPS will encrypt the traffic and prevent Man-in-the-Middle Attacks, making it impossible for anyone to eavesdrop, whereas Basic Auth will not.

So in that sense, the HTTPS based method is more secure.

You could get the same benefits regarding encrypted traffic for Basic Auth by adding HTTPS with a certificate that is commonly trusted by browsers (not requiring client-side authentication apart from Basic Auth)

In practical terms, you don't have to have the same password for everyone in the company. I think this is the greatest security flaw apart from any method, if security is a concern. Instead, you could have individual accounts (or client-side certificates) for each person. If a person leaves, you only have to invalidate that account. It also gives you the ability to detect who, and from where, uses certain accounts, and if an account is identified as compromised, you can close that account without affecting others.

The best of all worlds, also counting practicality, would be Basic Auth with individual accounts combined with a commonly trusted HTTPS cert.

If you are willing to compromise security, for example by having a single account for everyone, quote "so we can use less time to manage it", then I don't know why there is a debate about TLS/Basic Auth in the first place, because no encryption can compensate for an insecure handling of information.

  • Thanks, this should increase secure and save time of the end user and the managent. – bronze man Oct 23 at 1:31
0

If something is not meant to be public it shouldn't be public in any way and there is no security-plan that can assure you that your public websites will be 100% safe. Security depends on a LOT of things. What you're describing in your post is to use authentication and encryption to make sure that your data will be accessed only by those that have the authority to do so. But what happens if e.g. a 0day come out for a small plugin that you may use etc... What happens then? What part of the plan (auth & traffic encryption) makes sure that the data are still protected?

Everything that faces the internet can immediately be considered a possible target. And even if you are safe today that doesn't mean that you will be safe e.g. after an update etc...

Since I don't have enough information about your infrastructure/situation I cannot really provide you a solution that will be a suit for your needs but some thoughts are:

  • Create an intranet
  • Use a VPN software on the servers that host your websites and connect through that.
  • ssh to the non-public network that those servers are part of and work from there.
  • Thanks, Vpn just make the websites difficult to use, and easy to not work if the vpn server dead, I do not seen any different from using the client certification of TLS. We put the server of websites in big datacenter with public ip to access data faster, put the server internally will make it access the data too slow to work. So the websites will access from public ip, I do not know any way to prevent it. – bronze man Oct 23 at 1:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.