How can I access Microsoft's Crypto API from a client side Web application? More specifically, access user's Windows-MY certificates through a web browser and use them to encrypt data. I've looked at CAPICOM but it is no longer supported by Microsoft. I've also looked into Java's Cryptographic Excention and MSCAPI provider but it does not provide the functionality I need.
You have quite a few questions on this topic. This answer relates to all of them.
First: your problems using SunMSCAPI is caused by an unlucky combination of Entrust's CSP prompting for password when it is not necessary and SunMSCAPI using a slightly strange way of deciding whether a certificate has a matching private key. Can you get Entrust to fix their CSP?
Second: if you cannot get Entrust to fix their CSP, your best bet is Java and JNI. I can see that you tried this but gave up. It is possible - it will probably give you a headache, but it is really the only viable cross-browser solution. Of course if you can live with an Internet Explorer-only solution (you mention CAPICOM) you can implement your own ActiveX/COM-object with the exact functionality you need.
Related
Secure sockets use a CN check against certs in a trust collection with the domain accepting or connecting. For myself I created a private and public set for localhost and that helps me debug locally. If I wanted to offer an SDK, would it be considered secure to distribute a .key and .cer X509 for this localhost debugging use-case? Or is it always not considered secure to have a .key in any open space at all, because of its potential misuse?
Sorry if this is discussed in other places but I cannot find out a clear answer on it.
This might be somewhat opinionated and also depends on your project somewhat, but I think the main risk is how people will actually use those. Some of them will use it for production for sure, because it is easier, or they don't understand keypairs and just want it to work and so on.
Any project should be secure by default, for everybody involved, including endusers and developers as well if your project is something like a library or component. Secure by default in this case would mean not providing an actual keypair, because that would potentially be a backdoor in case of at least some of its uses - even though it was not meant to be used like that.
Another thing to consider is the reputation of your project. If you include a key and users misuse it on the internet, it will be easy to find and potentially exploit vulnerable instances of your project with tools like Shodan. Nobody will care the developers did it wrong - it will be your project that's found vulnerable.
A better way to consider would be to provide something like an init script that would generate a key and a certificate for that specific instance. It could still be easy for the user and developer, and also secure for everybody. In case of a linux package, this could even be done by the installer script with most packaging solutions so it would be fully transparent for the user.
I'm trying to secure my play application but I have no idea where to start. In play tutorial I have not found any chapter about that topic. As far as I see security topic is changing between play versions. So what are You guys using to secure Yours applications.
I'm new in Play so please forgive me if I'm asking obvious questions.
Edit:
Ok, maby question was't clear enough(I'm really sorry about that). When talking about security I mean that I need something to deal with users credentials and tool which allows me to restrict access to some pages and eventually to some rest actions in my application.
Edit2:
I'll try deadbolt2 now and we'll see how does it works. But I still encurage You guys to share Your knowledge about Play security with others:)
The documentation seems to still be a bit lacklustre on this topic, but essentially, authentication/authorisation functionality is usually performed using Action composition, which is the basis of reusable controller code in Play. There an example here (also linked from the docs that should help give you the general idea.)
Action composition in Play 2.2.x is done using ActionBuilders. These take a block which accepts a request and returns a Future[SimpleResult]. This allows the action builder to either execute the given block, or return a different Future[SimpleResult] (say, an Unauthorized in the case that a user's credentials did not check out.)
In our app we use the Play2-auth module for handling authentication with session cookies. This has (just) been updated to work with Play 2.2.x but uses a slightly different mechanism for action composition (stackable controllers.) You might be best off working out how the precise functionality you need can be accomplished just using the native framework tools before adding a dependency to it.
I agree with the other answers but just add that I use securesocial to integrate with other auth providers (google, FB, etc...), so I don't have to do auth myself. It's quite easy to get up and running.
https://github.com/jaliss/securesocial
Access control, security, etc. is a very wide topic, because it means very different things depending on context. This may be one of the reasons why Play has little documentation for it, which puzzled me at the beginning as well.
Play2 has some security helpers, namely it's the Authenticated method, for some insights on how to use it, check the comments in the source code. Its a simple method that you could implement yourself, and most do. It, essentially, just proposes a structure for where to place your methods that would check if request is authenticated and what to do if it's not.
Play2 also has some cryptography logic, which is used for signing cookies.
That's about it, you don't have any more pre-built security structures, but that's a good thing, because you don't want the framework making decisions like that for you, if it doesn't know in what context it will be used.
What is essential is to go and research how attacks relevant to your application are carried out, best practices and so on. I recommend going to OWASP, particularly the OWASP Cheat Sheets. If the list of Cheat Sheets seems intimidating start with the OWASP Top Ten Cheat Sheet. Don't mind the large volume of information, it's very useful knowledge.
Hi this is my first post here. I am developing a website project with public user registration and log in functions. Right now, I am conceptualizing the logic flow of the whole project and currently stuck at the authentication and security part.
I have googled and unable to find an answer. I also searched sof but effort is futile as well. What I want to ask is quite specific.
From what I read at other sof posts, it seems that to mitigate a brute-force attack, ip banning or time delay after n number of attempted log ins is one of the best solutions. Of course not forgetting whitelisting and blacklisting and Captcha. Of course I already plan to implement the above-mentioned techniques.(maybe not captcha)
My question is, is it possible to detect javascript enabled or unabled to block illegitimate log-in attempts base on the assumption that bot-net or 'hackers' do not use a javascript enabled browser to do their 'work'?
For example, "if js disabled, stop the 'rendering' of the log-in
form. //brute force attempt detected"
Finally, this assumption is base on the fact that all of my users will have a js enabled browser in order to use my website.
This approach will be run concurrent with other mitigate methods.
Please enlighten.
Thanks!
Not reliably or efficiently. You can't really trust anything that comes from the client side.
Anything you ask the client to do in javascript to prove that javascript is present can be impersonated. Forcing them to impersonate will force them to be more intelligent and expend more resources, which might be a win for you.
While u2702 makes a good point, I think it's good to keep in mind that just because a solution doesn't dissuade all attackers doesn't mean it should be abandoned. In fact, I think this is a quite good method to deter the vast majority of bots.
To answer the question at hand, you could have all prospective users calculate the MD5 of a value you've generated using a cryptographically secure random function. Faking this without javascript would be more-or-less impossible (as far as I can see).
Disclaimer: Implementation of this method will ban Richard Stallman and people who use NoScript from your site.
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/
Just to be on the safe side, what's the best practice to ensure that only my application has access to my webservice, which is hosted on a public server? Should I implement I shared key or something?
My webservice is hosted on Googles App Engine and my Application runs on iPhones and iPads.
If you need further information, just ask.
Thanks,
Henrik
some sort of challenge/response authentication would be your best bet, but you could use something as simple as a key that's sent with every request. it might be quite easy for someone with a packet sniffer to reverse engineer that security though - i guess the amount of time you spend on it will relate to how much you really care :)
If you require your iphone app users to enter a loginid/password, then it is trivial to achieve what you want. But I assume you don't want that ..
Without that, there is no way to ensure you app has exclusive access to your web-services. People can always sniff HTTP traffic and spoof it. People can decompile/reverse-engineer your app to figure out the key/password.
See other discussions on StackOverflow - How to restrict access to my web service? and How can I create and use a web service in public but still restrict its use to only my app?
You could program your app to only serve requests that include your iPhone's unique identier - see StackOverflow question [Unique identifier for an iPhone app]. The id could still be sniffed, so depending on your needs, you may need methods to counter that.
Well, i had similar problem. What i realized, there is no 100% solution. What i did is, i used different approach. I have implemented OAuth and SSL, of course and than make algorithm for my web service to learn behavior of my app.
I try to put that algorithm in some kind of pattern, template, so it can be used in more scenarios. It's still in developing, so here is code of simple console app that will simulate that algorithm. Hope this can help:
https://github.com/vjeftovic/LearningRESTSimulation