In my application, the client must sign (using a certificate) and send data to the server.
My doubt is how should I do it?
To sign on the client side, I should use ActiveX right? My problem is that firefox doesn't support it.
Signing on the server side I have two options:
Save the private key on the server and use it when necessary (if the data is modified during the transaction it will sign false data)
Send the private key when necessary (may comprise the key)
Despite using SSL, I'm not very confortable with any of the two options for signing on the server side...
Using ActiveX may cause my application more vulnerable, right?
Hope you can help me :)
There's no single solution for client-side signing in all browsers, unfortunately. We are currently working on distributed signature components for our SecureBlackbox product, and we've created Java applet, ActiveX control and Flex script to perform signing. However, all variants have shortcomings. For example, only ActiveX control can access windows certificate store. With other module types the user would need to load the certificate from PFX (PKCS#12) file.
Uploading and signing on the server won't work because the private key is not always exportable on the client (it can reside on cryptotoken or smartcard, or just be non-exportable), and also this approach makes the whole process useless as it significantly lowers security.
Update: SecureBlackbox 9 is in public beta now, with support for client-side signing (we provide ActiveX, Java and Flash modules for this).
Related
I need a little guidance on how to implement signing of documents in a web based document distribution system we are developing.
At its simplest, user A will be logging into the website and create a Data Package. Word/Pdfs can be added to the package. User A will sign this document(s) using a digital certificate. User A might assign this to other users for reviewing the documents. They may sign the documents as well.
Now I know how to digitally sign data with C#. What I don't know is how to generate a certificate when each user logs into the website. The site is secured with DigiCert certificate.
What approach should I take to generate a digital certificate for each user? Once I have a .pfx file I believe I can store it in the database and use that.. Any guidance on this matter will be greatly appreciated!
thanks
I take to generate a digital certificate for each user? Once I have a .pfx file I believe I can store it in the database and use that..
This is what I call "naive approach" (read simplistic). You consider to store (maybe even generate) keypairs for the users in a web application. The biggest isssue with this approach is that someone with low-level access to the system (admins) or if database is leakt could gain access to the user's private key. To have a secure solution (considering signing), the private key may not leave its user
Doing everything in a web environment, you may consider using SubtleCrypto or other client site libraries, however at this point of time I see no reasonable way to manage the keys for pure web apps. Maybe you can store the user's keys and certificate in a localStorage, but it leaves some space for mallignant scripts to leak the keys.
Many real life secure solutions are working with secure modules (e. g. crypo cards), unfortunatelly the web libraries have no access to the modules (usually exposed as pkcs11 interface). As a solution usually the signing piece runs as custom code on user's computer. Before it was ActiveX, Applet,.. now it is often a "driver" exposed as a web server bound to "localhost" so the signig service can be used as web api from web applications.
I'm implementing 2FA on my app with phone number verification. As SMS are not free, I really need to ensure that a request to my server comes from my app and not from any third party http request launcher.
For this purpose, I thought about encrypting the http request with a key provided by my server within my app, and send that encrypted request. As my app is a binary (this is not applicable for web of course), I was thinking it would be difficult to see the encrypting method. The process would be the following :
my app asks my server a key
my server generates, stores and returns a random key
app encrypt the whole actual request with a "secret" method, depending on that key (secret = in binary so hardly readable)
app send to server the encrypted request + the key
The server sees if the key exists, and tries to decrypt the request. If it manages to decrypt, it proceed the request, and then remove the key from its storage so no one can use it anymore.
I don't see any to compromise this system, except if someone manage to read from apple/android binary app the encrypting system the app uses.
Do you think this can be a good process ? Do you see any way to compromise this system ? Is reading from a binary file is really difficult ?
I will start with the flaws in your design, from an android perspective, even if you have enabled pro-guard for your app, we can still decompile the app and trace back the api calls
If your server is not using HTTPS - its easy to trace the calls going
back to the backend server by routing through a proxy server like
charles proxy, and analysing the response, even if you are using
https its possible to install ssl certificates to trust the proxy and
get the response. Also by analyzing the outbound requests its
possible to extract the signed key from the app
Its easy to decompile an apk package and opening it in IDEs and
searching for the backend server url by inputting 'api' or
'http','https' keywords on the ide project search window
If you are storing the secrets in shared preferences or storage, it
can be read from the device ,if the attacker has root access to file
system.
then remove the key from its storage so no one can use it anymore.
For the above scenario, i will run the app and once it stores the key , i can change the permission to read only , so even if the app tries to remove it , it wont be deleted
You can use SSL-Pinning, and putting the keys in compiled libraries making it difficult for the attacker to decrypt the key, also you need to make sure that you don't create any other loop holes
You may also share the common key between app and server through alternate channel , like an email . Where the user once he registers for the App gets and Email with a QR code which once scanned will give the server key. The security of this approach is tied to the secure access of the email by authorized user.
You may them follow the standard approach of sending the encrypted request to server to verify the phone number , once done you may delete the data form your app storage.
I am planning to implement API security in my REST application, Where i need work for authorization URL (on server PHP application) which will return a session token to client (mobile clients android, iphone, BB, wp7, wp8)requesting this url.
After looking for possible solutions i found these two perfect for my needs. but i am not able to decide on solution which will survive me on long runs.
Using RSA encryption with openssl for transferring user data to authorization URL (i am going with openssl just to stick with standard and secure method).
I have a hunch that it's possible to just use HTTPS to pass the user data and let OS handle encryption/decryption.
However, I am particularly inclined to first approach, since here client will not be able to make successful call to authorization url unless it has access to public key. But i am not sure about how well this approach will gel with all mobile clients.
Any help on this is much appreciated!..
You should be ok when sending the authentication URL over SSL. SSL will authenticate the server and make sure that the data is protected against eavesdropping and man in the middle attacks. The URL will then be send over this protected channel, so after verifying the URL, the server can determine that the client is indeed the right entity. The token can then be safely send to the client over the same SSL session
If you go with your own scheme you will have to setup your own key management scheme and protocol. This is extremely hard to get right. Your comment on having access on a public key is a good indication that you will fail. SSL is not perfect either, but it has had a lot of scrutiny, and chances of it failing out of the blue are slim.
In other words, choose #2 over #1.
Suppose I have a valid (i.e. signed by one of the commonly trusted authorities) cryptographic certificate on my server. I could obviously use it to establish https sessions and deliver the contents with confidentiality (only the endpoints can read them), authentication (both endpoints know who they're talking to) and reliability (the message can't be tampered).
Now suppose that I actually don't care about the first two but, instead, I just the need the last one. For example, let's say I have a static resource that I would like to sign (a-la PGP) so that I can give it to other untrusted hosts: if my certificate is public and the resource has been signed with it, any client should be able to verify that the resource has not been tampered (e.g. by the untrusted host).
The question now is: is there a standard way to statically sign a web page? (I obviously mean something builtin in all browsers) I'm aware of someone (Unhosted) who's trying to accomplish something like this by implementing much of the logic via Javascript but still I'm wondering if a more standard way exists.
I'm not aware of any such standard implementation builtin in a browser.
Even in the mail area where such behavior is "standard" for long time (S/MIME), we find issues every other day with different clients, relays and servers.
For a download you may revert to sending a PKCS#7 container and associate a tool that unpacks and verifies. At least plugins and helper applications are availabel everywhere.
I'm also not aware of any standard implementation like that within a browser. But, to back up a bit... some things to consider:
For executable content (like downloaded EXE files, ActiveX controls, Windows Installer, etc.), a common / standard solution is Microsoft Authenticode. See http://www.tech-pro.net/code-signing-for-developers.html. Similar solutions for Java, Adobe, etc. The CA you buy the cert from will verify your identity. When you sign an EXE file with a cert from a trusted CA, Internet Explorer will display the signer information / less scary warning message. Same goes for UAC elevation prompts in Windows Vista/7. You're probably familiar with this?
But for the static content situation, the standard solution is SSL. May I ask why SSL isn't an acceptable solution in your application?
The problem I see is that there's no way for the user to verify the identity of the web page from the web browser, other than clicking the SSL "lock" icon in the browser to view the certificate. The new SSL EV certificates should verify that you control the domain in question, and that you are who you say you are (i.e. not be able to get a "PayPal" certificate for www.paypal.com.hacker.cz).
It sounds from your question that you're looking for an "Authenticode for web pages" sort of thing: a certificate with a subject not tied to a domain name and where the web page could go anywhere. Unfortunately, I'm not aware of any such thing for standard HTML files. I believe you can sign things like Adobe AIR applications, which can be based on HTML / Javascript / etc., although I'm not familiar with that platform. It does place the web page outside of the user's normal web browser, of course.
Something I can't wrap my head around is how secure web services are.
For example we're writing a desktop application that will interact with data on one of our websites as well as local data. This data is sensitive though and the last thing we want is anybody calling the web services.
I've not yet found anything that says web services has some kind of authentication methods and the only security I've seen people talk about is using certificates to encrypt the message.
I'm no guru on this and would appreciate anyone's input and perhaps a link to somewhere that will explain this in simple terms.
Thanks
Jacques
If you are using ASP.NET to create a response / request Service you have only 3 options
ASMX
WCF
Normal .NET pages (or handlers) to process requests
as you specify Services, you can choose between ASMX and WCF then (you can read the difference between ASMX and WCF in my answer here)
keep in mind this
ASMX is considered deprecated technology and replaced by WCF. So if you are going to start new development which requires exposing reusable services, WCF is the way to go.
This days, there is a common pattern when we need to secure Services, and that's using a session key.
The Service normally has a Method for Login where it gets a User and some kind of Password (normally hashed, salted, etc) and that returns a "ticket" that has a limit of time (slided or not - means per each call to a method the period get's reseted or not), and all calls need to have that ticket included in the message body.
Services API like Magento and others uses this.
Or having a pre generated key that is given to the user / application to be used with every call
Services API like Campaign Monitor and MailChimp and others uses this.
The other normal way is to have the user and other credential in the message header all the time.
Services API like SuperOffice CRM and others uses this.
None of this services uses SSL, as I would only use if I really needed to protected the data in the "wire" keeping in mind that SSL expands the response time on every call made.
I hope this helps
Authentication:
Consider securing your web services with SSL. Distribute client certificates to those who need to consume those web services. Configure IIS to "Require Client Certificates".
Authorization: Consider developing a scheme where the user is sending a username and password of some kind in the querystring. When you can determine that those credentials are permitted to perform the operation that they're requesting, you can allow them to proceed. Indeed, this is custom logic that the application developer needs to write. There are no built-in conventions in ASP.NET web service for this.
The SSL encryption occurs at a lower level from the application. It's the applications job to then determine who is allowed to perform what operations.
Our webservices are encrypted through SSL (the certificates part) which is https://www.yousite.com instead of http://www.yoursite.com. This just provides basic encryption for the data stream. See SSL.
They are also authenticated by the authentication method that is chosen for our website. If it's is windows auth, or forms auth. See the msdn page on ASP .NET authentication.
For XML Web-Services you should take into account the following best practices:
Secure the transport Layer: the infromation or data in XML cannot be interrupted and read in transit.
Mask internal resources: Use Network Addres Translation (NAT).
Implement XML filtering: With the heklp of XMLand SOAP, affective filtering policies can be set to a content level that requieres a fully parsed or processed XML document.
Validate, Transform, Sign and Timestamp al messages: Use XML Schemma Validation, use XSLT for transforming XML, sing all messages, use Network Time Protocool (NTP) for synchronizing all XML nodes to a single authoritative reference time source.
Encrypt message fields.
Implement secure auditing.
Use existing security methods such as HTTPS.
Perform XSL transformations on the server.
Source: EC-Council Secure Programmer.
To expound on previous answers: Web Services are as secure as you make them. In general, there are two types of security. Securing the Transmission, and securing the access. Use of SSL can make your transmission secure (). Using Authentication (demand a username and password) allows you to secure access.
Web Services accessed via public internet (that is: not a VPN or only internal resources) are, indeed, less secure than Windows applications, since anyone can have access to them and, potentially, attempt to break your security. By using both transmission and access security, you can mitigate that to acceptable levels (acceptable to the point that banks use them for financial transactions, and you don't know paranoid until you've talked to a banker who has to face an FDIC inspection).
All web applications are exposed to the attacker and are a great surface area for attack. The biggest problem with web services, such as SOAP(WCF) is that often times the programmer doesn't realize that its trivial for an attacker to gain full access to the service. Often times programmers expose nasty functionally like execute_sql_query().
You should read the entire OWASP top 10.
Here's a primer on Securing XML Web Services Created using ASP.NET.