Our Penetration testing Team is suggesting to configure Public Key Pinning Extension for HTTP at IIS level.
Wikipedia says it’s a deprecated security mechanism. And most of the blogs and articles not recommending pinning because it involves a huge risk.
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning
https://threatpost.com/google-to-ditch-public-key-pinning-in-chrome/128679/
Is it any good to have PKP on a Web site?
Please Advice.
What I can make sure is that compared to websites that don’t use any certificates or encrypted connections, public key pinning can make connection safer. When Google first introduced PKP, it was used to add a layer of security for web clients.
But after so long of technological changes, more safer technologies appear, which make PKP looks not perfect.
By terminating the connection PKP can help protect end users from man-in-the-middle (MITM) attacks. One way a MITM attack can happen is when an attacker uses a fraudulent certificate to create a spoofed site in order to harvest user’s personal information.
Now it seems that PKP is not safe, few websites use it, and even many browsers are giving up support for it. I think your Penetration testing Team know this, but why they insist on using it, you need to ask them. They may have some specail reason for using PKP.
Related
Here is my requirements:
Usable by any mobile application I'm developing
I'm developing the mobile application, therefore I can implement any securing strategies.
Cacheable using classical HTTP Cache strategy
I'm using Varnish with a very basic configuration and it works well
Not publicly available
I don't want people be able to consume my API
Solutions I think of:
Use HTTPS, but it doesn't cover the last requirements because proxying request from the application will show the API KEY used.
Is there any possibility to do this? Using something like a private/public key for example?
Which fits well with HTTP, Apache, and Varnish.
There is no way to ensure that the other end of a network link is your application. This is not a solvable problem. You can obfuscate things with certificates, keys, secrets, whatever. But all of these can be reverse-engineered by the end user because they have access to the application. It's ok to use a little obfuscation like certificates or the like, but it cannot be made secure. Your server must assume that anyone connecting to it is hostile, and behave accordingly.
It is possible to authenticate users, since they can have accounts. So you can certainly ensure that only valid users may use your service. But you cannot ensure that they only use your application. If your current architecture requires that, you must redesign. It is not solvable, and most certainly not solvable on common mobile platforms.
If you can integrate a piece of secure hardware, such as a smartcard, then it is possible to improve security in that you can be more certain that the human at the other end is actually a customer, but even that does not guarantee that your application is the one connecting to the server, only that the smartcard is available to the application that is connecting.
For more on this subject, see Secure https encryption for iPhone app to webpage.
Even though it's true there's basically no way to guarantee your API is only consumed by your clients unless you use a Hardware secure element to store the secret (which would imply you making your own phone from scratch, any external device could be used by any non official client App as well) there are some fairly effective things you can do to obscure the API. To begin with, use HTTPS, that's a given. But the key here, is to do certificate pinning in your app. Certificate pining is a technique in which you store the valid public key certificate for the HTTPS server you are trying to connect. Then on every connection, you validate that it's an HTTPS connection (don't accept downgrade attacks), and more importantly, validate that it's exactly the same certificate. This way you prevent a network device in your path to perform a man in the middle attack, thus ensuring no one is listening in in your conversation with the server. By doing this, and being a bit clever about the way you store the API's parameters general design in your application (see code obfuscation, particularly how to obfuscate string constants), you can be fairly sure you are the only one talking to your server. Of course, security is only a function of how badly does someone want to break in your stuff. Doing this doesn't prevent a experienced reverse-engineer with time to spare to try (and possibly succeed) to decompile your source code and find what it is looking for. But doing all of this will force it to look at the binary, which is a couple of orders of magnitude more difficult to do than just performing a man in the middle attack. This is famously related to the latest snap chat flurrry of leaked images. Third party clients for snapchat exist, and they were created by reverse engineering the API, by means of a sniffer looking at the traffic during a man in the middle attack. If the snapchat app developers would have been smarter, they would've pinned their certificate into their app, absolutely guaranteeing it's snapchat's server who they're talking to, and the hackers would need to inspect the binary, a much more laborious task that perhaps given the effort involved, would not have been performed.
We use HTTPS and assign authorized users a key which is sent in and validated with each request.
We also use HMAC hashing.
Good read on this HMAC:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
Wondering if ReSTful webservice is really the answer in my case of Enterprise application where there are some security concerns such as avoiding man-in-the-middle attacks, ensuring that a trusted client is connecting, client being sure that it is indeed talking to the real server etc.
Is HTTPS the solution? Have read some concerns being raised about its adequacy and fitment, although with a not-so-strong background in IT/application security, don't quite understand, why so!
I see ReST being talked (/ raved) about, and being projected as The-thing, and do see its adoption picking up, by can't seem to understand why the security thing isn't such a big concern, and if it is, what can be done about it.
If you are really serious about securing your service and avoiding man-in-the-middle attacks you should issue certificates to your clients and only accept requests that are signed with those certificates. It is more work for you and for your clients, but in an Enterprise setting, the extra effort may be worth it. It is definitely an option that is worth looking into.
Out of the box you are not going to have any type of message level security, and you would need to leverage HTTPS to do transport level security.
I have seen people attempt to use signed atom feeds, but its nothing to the level of the WS-* stack that comes with SOAP.
I consider myself to be quite a good programmer but I know very little about sever administration. I'm sorry if these questions are noobish but I would really appreciate some advice or links on steps I can take to make this more secure.
I've completed a project for a client that involves storing some very sensitive information, ie personal details of big donors. From a programming perspective it's protected using user authentication.
I don't mind spending some money if it means the info will be more secure, what other steps should I take?
Can the database be encrypted some how so that even if the server is compromised people can't just dump the mysqldb and have everything?
Is it worth purchasing an ssl certificate?
The site is currently hosted on a personal hosting plan with a reasonably trustworthy host. Would a virtual private server be more secure? Are there special hosts I can use that take additional steps to protect info (ie would it be more secure on amazon s3)?
As a side note to the specific question, I would recommend reading some books on computer/programming security. Some good ones are 19 Deadly Sins of Software Security and Writing Solid Code.
You don’t need to encrypt the database itself, just encrypt the data before storing it. (Make sure to use real, cryptographically-secure algorithms instead of making one up yourself.)
Using SSL is definitely an important step if you want to avoid MITM attacks or snooping. A certificate allows you to use SSL without having to take extra steps like installing a self-signed one on each of the client systems (not to mention other benefits like revocation of compromised certs and such).
It depends on just how sensitive the information is and how bad leakage would be. You may want to read some reviews of hosts to get an idea of how good the host is. (If possible, sort the reviews ascending by rating and look at the bad reviews to see if they are objective problems that could apply to you and/or have to do with security, or if they are just incidental or specific issues to that reviewer.) As for the “cloud”, you would kind of be taking a chance since real-world security and privacy of it has yet to be determined. Obviously, if you do go with it, you’ll want a notable, trustworthy host like Amazon or Microsoft since they have benefits like accountability and work constantly and quickly to fix any problems.
HTH
I am working on a project that requires user login/registration. I'd like to avoid setting up private SSL since I am using a shared hosting provider and would like to host multiple domains off of the same plan (but since a private SSL certificate requires a dedicated ip, I can only have 1 certificate per plan...but would still like to secure all of my sites).
I am debating between
resorting to OpenID (although for a non-technical audience all the complaints I found on SO would be further multiplied)
using my host's shared SSL (which will pop up those annoying certificate warnings in the browser saying that the sites don't match).
What seems like a better option? Or would you suggest run away from both and just suggest sucking it up and purchasing additional/better hosting plans?
From my experience in dealing with SO and a fairly simple site using Google App Engine (and their authentication system), I'd give the following advice:
Do NOT use OpenID for identification. It can work for authentication with your own identity management, but there are issues as soon as you try to identify a specific user.
Its amazing how many open ids people will have, so be prepared to support multiple OpenID auth URLs (definitely more than 1, probably more than 2)
If high security is a requirement, be very wary of OpenID. Many people will use providers that they normally only use for low-security tasks (and therefore have weak passwords). This particular issue struck Jeff Atwood directly (his account was stolen due to exactly this mistake)!
Keep things simple for your users. If you do go with OpenID, emphasize one or two providers that they likely already have (eg, Google), and then provide a deemphasized selection for generic providers. Don't make the more simple-minded users think about OpenID.
Along with that thinking, a simple "Login with your Google Account" button works surprisingly well. I thought people would find it confusing to login to a third party site with their google account, but in practice this has not been a problem with our .appspot.com domain.
The bottom line is that you shouldn't expect your users to prefer openid, but it can be an acceptable compromise. I don't think that showing an invalid certificate is a reasonable option for many end-users.
Of course, the separate certs option is the cleanest, but you have to decide if thats really worth it for the value gained. I'm a cheapskate and would tend to avoid it myself. :)
Why not roll your own from the ground up? If your database is accessible from each domain, you could keep one user store that every domain could access.
Is there a particular reason you do not want to create your own user model? It's easy to do but you may have other factors that are leaning you towards something like OpenId that I am not aware of.
If you use the shared SSL's URL, you shouldn't get the popups. That's the whole point of shared SSL. What you is the identity of your site's URL when the user jumps to the secure connection.
I would talk to your hosting provider about your options when it comes to private SSL. They're really not that expensive (even free if you're ok with poor IE support). I've been with shared providers in the past that would allocate you a dedicated IP for use with SSL for a tiny extra fee (like $2/mo).
To me, the extra $54 per year ($30 for the cert + $24 for the IP) was well worth the peace of mind for me and my users.
There are a few questions (C#, Java) that cover how one might implement automatic updates. It appears initially easy to provide automatic updates, and there are seemingly no good reasons not to provide automatic updates for most software.
However, none appear to cover the security aspects of automatic updates.
How safe are automatic updates now?
How safe should they be?
How safe can they be?
My main issue is that the internet is, for all intents and purposes, a wild west where one cannot assume anything about any data they receive. Automatic updates over the internet appears inherently risky.
A company computer gets infected, spoofs the DNS (only a small percentage of which win), and makes the other company computers believe that the update server for a common application is elsewhere, they download the 'new' application and become infected.
As a developer, what possible attacks are there, and what steps should I take to protect my customers from abuse?
-Adam
With proper use of cryptography your updates can be very safe. Protect the site you distribute your updates from with SSL. Sign all your updates with GPG/PGP or something else, make your clients verify the signature before applying the update. Takes steps to make sure your server and keys are kept extremely secure.
Adequate, is very subjective. What is adequate for a internet game, maybe completely inAdequate for the security system for our nuclear missiles. You have to decide how much potential damage could occur if someone managed to break your security.
The most obvious attack would be an attacker supplying changed binaries through his "evil" update server. So you should ensure that the downloaded data can be verified to originate from you, using a digital signature.
To ensure security, obviously you should avoid distributing the key for the signature. Therefore, you could implement some variation of RSA message signing
Connecting to your update server via SSL can be sufficient, provided your client will refuse to connect if they get an invalid certificate and your server requires negotiating a reasonable level of connection security (and the client also supports that).
However realistically almost anything you do is going to be at least as secure as the route via which your users get the first install of your software anyhow. If your users initially download your installer via plain http, it is too late to start securing things on the updates.
This is also true to some extent even if they get your intial software via https or digitally signed - as most users can easily be persuaded to click OK on almost any security warning they see on that.
there are seemingly no good reasons not to provide automatic updates for most software.
There are good reasons not to force an update.
bug fixes may break code
users may not want to risk breaking production systems that rely on older features