CODEWITHSUNDEEP
httpauthenticationhttps
Dani Cricco
Dani Cricco

Reputation: 8979

http or https authentication for Intranet Web applications

I’m developing an Intranet application and I want to make a secure authentication.

One approach can be use “https”. The problem is that the server doesn’t have a trusted certificate, therefore is a bit annoying for the client because the browser doesn’t trust in the certificate and complaints with a scary message.

Using http will compromise the user password but it can be combined with “Digest access authentication”

What do you think?

Upvotes: 15

Views: 24046

Answers (5)

Eric J.
Eric J.

Reputation: 150138

2023 Update

Cloud vendors allow you to automatically provision SSL certificates for non-public domains (e.g. AWS Certificate Manager). There are also self-hosted private certificate managers such as this one.

SSL for intranet/internal cloud connections is strongly recommended and may be required for PCI and SOC 2 certification.

2009 Answer

Purchase a domain and trusted certificate? They are really not that expensive anymore if you shop around.

Having said that, digest access authentication is reasonably safe for authentication. Using http rather than https, all of the information you send across the wire will be plain text even if the password is not. Anyone that can plug a laptop in to your intranet running an application such as WireShark can view all of the information sent back and forth. If you care about that information not being compromised, http will not meet your needs.

Upvotes: 6

Peter V. Mørch
Peter V. Mørch

Reputation: 15957

These are (y)our options:

  1. If you have mostly Windows hosts, you can Distribute Certificates to Client Computers by Using Group Policy | Microsoft Docs and use your own self-signed certificate in this way.

    • Non windows users or Windows machines not in the domain will have to go through the hoops and warnings of either installing the certificate properly manuallly or allowing the self-signed certificate. A bad user experience.

  2. You use a proper domain name, a real certificate and a messy DNS configuration where www.mycompany.com resolves to an external site, but wiki.mycompany.com is an internal site (But please, please don't put the internal address for wiki.mycompany.com in an externally visible DNS record!)

  3. You don't use HTTPS at all and use HTTP. Possibly by inventing your own security for login pages (Yikes!)

They all suck.

Especially if you want to distribute an enterprise-ready onsite app, and you don't know the customer's network and DNS configuration beforehand.

Upvotes: 11

Timmmm
Timmmm

Reputation: 96822

As of November 2015 you can't buy certificates for internal domains so as far as I know the only option is to pre-install the certificates on clients. Not a great solution.

Another possability if you want to keep your internal domains private is to create a public domain: mycompany.com, and then run your own DNS server internally that resolves your internal domains: accounting.internal.mycompany.com, hr.internal.mycompany.com and so on. Then I believe you can use a wildcard certificate for mycompany.com. I haven't tested this solution.

Upvotes: 8

Jan Soltis
Jan Soltis

Reputation: 4429

You have these options:

  1. Purchase a trusted certificate.

  2. Or, generate your own root certificate, install it in browsers on all intranet computers (you should be able to do it since it's intranet), generate your own server certificate signed with your own root certificate. This is actually what companies often do.

Note: Digest access authentication is not helpful if you want to have form authentication (a HTML form with user, password, login page using the visual style of your app, nicer wrong-password error reporting, possibly additional features such as "remember me" or "forgot password").

Upvotes: 4

jaywon
jaywon

Reputation: 8234

If you need it to be a fully secure, you should purchase the SSL certificate.

From the wiki link you provided:

Disadvantages

Digest access authentication is intended as a security trade-off; it is intended to replace unencrypted HTTP Basic access authentication which is extremely weak. However it is not intended to replace strong authentication protocols, such as Public key or Kerberos authentication.

I think there's your answer :)

Upvotes: 1

Related Questions