Is there a way to restrict access to a website based on ssh keys? Exactly the same way ssh works:
If you have a key, access granted -- no password
If you don't have a key, access denied
If not, what is the best alternative that would satisfy the above conditions? Would I be better off using htuser? I can't restrict access based on IP addresses because the people accessing the site will most likely not always have the same IP.
Sure, using Mutual-SSL-Authentication you can secure your website using SSL certificates.
I don't know your environment, but here's a pretty detailed writeup on how to perform mutual authentication on Tomcat.
Related
I use letsencrypt for my platform, securing multiple websites.
I can prove i am the domain owner, then generate certificate, by controlling the origin and response to the challenge, but if my website get spoofed (let say with a bgp hack), is there a way to force letsencrypt to use, for example, DNS validation ?
This would harden the setup since it would need an attacker to hack both the access to my origin and access to dns in order to generate a certificate with my domain name. Maybe there is another way ?
Thanks !
i did multiple google research, i expect pointers in order to harden my letsencrypt setup
I've got server with w2k8 and IIS7 in one domain and keytab from some other foreign domain (no trusts). Is it possible to enable Windows Authentification (SPNEGO/Kerberos) to auth users in Web Application from the those foreign domain?
It's theoretically possible, but the logistics of making it work are next to impossible to implement.
I've no idea if IIS supports this or not, but it is possible in the kerberos API to say
"try to decrypt this response using every key in the keytab". In theory, this can be used
with keys from remote realms, although I've never seen code attempt it.
However, the problem is the client needs to decide the realm and principal to use to make
the request based on information outside the protocol. Thus you'd need to somehow tell all the
web clients from the remote domain to use the remote domain when contacting the webserver
in the w2k8 domain. You can do this with krb5.conf on unix machines, but it would require a
custom krb5.conf on every client using identities from the remote realm.
In general, kerberos will only work across multiple realms if there is some kind of cross realm
trust enabled.
This is a very general question, not sure if its a duplicate as I have not really found my answer yet.
My company is very concerned about security of data, means, we are very particular about hosting our app and also our database. We are dealing with quite sensitive information such as medical data. We previously used AWS, means using a raw instance with no SSL at all. We migrated our web app to Heroku, as its purchased by cloudforce and we do not really need to take care about security, pen-testing all these stuff.
Then, we used heroku's SSL endpoints with a goDaddy SSL Cert which we think it might further enhance the security of the site.
I can say I am super noob in web security but are these measures enough?
If you are dealing with medical data, the measures you describe are not enough by themselves.
An SSL certificate will ensure your data is protected (encrypted) when it goes over the wire. A certificate will also identify the server to your users (mitigating man-in-the-middle attacks).
But when dealing with sensitive data, you'd also have to make sure your data is protected at rest (encrypted in the database or encrypting the database files themselves). You also have to take measures to prevent unauthorized access. This means that your users need to authenticate themselves and you have to give them access or prevent them from having access based on who they are or what role they are in (RBAC).
Google for any of the terms in this answer will give you lots more information.
It indeed is a general question, so only a general answer can be provided. Furthermore, it all depends on how you define "enough".
Of course using SSL give you the advantages of it, you are better of with it than without.
But make sure that you understand what SSL does and does not do. A limited list:
SSL does encrypt the communication between client en server.
SSL does conform the identity of the server (if he manage to keep his private key secure).
SSL does not prevent any acces to your endpoint
SSL does not conform in any way the identity of a user.
One great advantage of using Azure Websites is that I can get secure HTTP (HTTPS) without doing nothing: I simply type https://xyz.azurewebsites.net and it works. I don't have to worry about certificates because I use the subdomain that Azure gives me (in the example it would be xyz)
So, what I usually do is that people come by through some registered domain I have, eg. http://www.my-application-homepage.com, and there, if they want to use my application, I redirect them to the subdomain at azurewebsites.net, using HTTPS.
Now, having said that:
I'm in need of upgrading to Azure Cloud Services or Azure Virtual Machines, because these have capabilities that Azure Websites don't . These two also offer a free subdomain: xyz.cloudapp.net, but my question is: will I get HTTPS there too? and how?
I searched in google for some cloudapp examples and what I tested was the following:
1) Connect through HTTP (ie. type http://xyz.cloudapp.net). Result: worked
2) Connect through HTTPS (ie. type https://xyz.cloudapp.net). Result: didn't work (chrome gave ERR_CONNECTION_TIMED_OUT)
No. HTTPS is not offered for .cloudapp.net domain as of today. Also since you don't own .cloudapp.net domain, I don't think you can buy a SSL certificate for that. If you want you could create a self-signed certificate and use that.
I would walk through the documentation listed here:
http://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
Since you're getting a timeout with HTTPS (rather than a certificate error), check that you have a HTTPS endpoint defined in ServiceDefinition.csdef.
Additionally, be aware that the redirect-to-subdomain approach isn't much more secure than using a self-signed certificate. The reason browsers reject self-signed certs is that they are vulnerable to spoofing attacks: a user can't detect if an attacker has, for example, hijacked the DNS to point to his IP address instead of yours, where he hosts a facade of your site that just collects passwords or whatever.
In your scenario, the cloned site could redirect to another a second clone, one that is a facade of your cloudapp.net site. It could be even be secured with the attacker's SSL certificate. Unless the user was trained to recognize the host name of the real cloudapp.net, she wouldn't know she was on the attacker's "secure" site.
** Update: This method is not valid as well, we got the certificate revoked after one week using it **
We use this approach for staging/dev servers:
If you don't want to use a self-signed certificate, one option is to purchase a cheap SSL certificate, e.g.:
https://www.ssls.com/comodo-ssl-certificates/positivessl.html
Then once you need to approve it you have to ask support to change the approver validation process: instead of sending an email to a admin#mydomain.cloudapp.net you can ask to change the validation process to placing a given file with a given file in the root of your website (you have to ask in the support / chat room about that option).
More info:
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/791/16/alternative-methods-of-domain-control-validation-dcv
How can i restrict access to the admin/ section of my website? I can't limit it by IP address because we need to sometimes access the admin/ section from remote client locations (when giving a demo, etc).
there is of course, an admin username/password - but what else can i do?
Most applications just use a username/password for access control, and that's generally sufficient. Some that require extra security use two-factor authentication, which might mean using a token that you carry with you (e.g. a device that generates a token that's kept in sync with a server) or a token that is sent to you (e.g. the system sends a text message to your phone with a token that you have to type in in addition to your password).
An easier option is to authenticate using a client certificate; you can carry the cert around with you on a thumb drive in case you're at a remote location (just remember to remove the certificate from the remote machine when you're done).
Here's a nice write-up on client certificate authentication.
Another option is to only allow connections from your local network, and then use VPN to join a remote machine to a local network.
if the admin interface is in an seperate folder, you can use .htaccess and http auth. the same can be done using e.g. rails to restrict access to certain routes (controllers).