I’m a software engineer and I’m currently working on another payment application (my 3rd one) that must go under PCI PA-DSS compliance. I’m re-examining the PA-DSS documentation and I’m wondering if in the past I overworked on the security of the application, when I could’ve go by with TLS and user/pass. So, my questions are, when implementing a PA-DSS secure application:
For Authentication and Communication security is it enough to have TLS + user/pass?
What part(s) of the PA-DSS standard justifies the need of implementing message hashing and rolling hash between web methods calls? TLS implements reliable messages, but not rolling hashes and persistent callers between messages. Will implementing a rolling hash make any difference (from the PA-DSS stand point)?
If a payment processing application stores PII information and serves different companies (meaning that Company A and Company B can have accounts in such application), there is no specific requirement that states the PII information cannot be stored in the same DB, but in the past, PA-QSAs have insisted in this being an issue. The question is: Is this truly necessary? I cannot think Authorize.NET, a company with thousands of clients and processors have different databases to store the credit cards processed through each of its client companies.
Thanks in advance!
Update #1:
Assume all pages and web services, both in DMZ and Secure Zone will have HTTPS for all the communication channels, pages and services.
On #3, the question is not about the location or security of the storage of sensitive information. The question is more geared to question the ability of sharing sensitive information from different sources (clients, such as AT&T and Verizon for example) in the same database.
There are a few issues here.
1) Using TLS for just the username+password is still a vulnerability. Its a violation of owasp a9 and its trivial to hijack any account on your system using a firehseep style attack.
I know the PA-DSS 2.0 doesn't embody the entire owasp top 10, but requirement 12.1 should be noted:
12.1 Instruct customers to encrypt all non-console administrative access with
strong cryptography, using
technologies such as SSH, VPN, or
SSL/TLS for web-based management and
other non-console administrative
access.
Which would include an administrative http interface.
2) The PA-DSS recommendeds using real transport layer security such as: VPNs, and TLS/SSL. I don't believe there is a requirement for rolling hashes, and to be honest this isn't a very secure design. Such traffic needs full transport layer protection.
3) Don't forget about requirement 9:
9. Cardholder data must never be stored on a server connected to the Internet
Related
i'm developing a simple news App where users can see latest news without login, i don't know how to make it secure, i have read that JWT with OAuth2 should be used but from my understanding the user have to login into a provider to get the token but i want users to be able to read data without login.
my concern right now is how to prevent other people from using my API in their apps, i'm concerned also about DoS attacks.
THE CHALLENGE
i'm developing a simple news App where users can see latest news without login, i don't know how to make it secure
Well you bought yourself a really huge challenge, because even if you required your users to login, it would continue to be a huge challenge, because the web as we know was designed in their earlier days with the naive assumption that only good faith people would use it, thus it becomes a very hard task to secure something that was not designed to be secure in first place.
Securing and locking an API server to a specific app requires that some kind of secret needs to be used in every request in order to authenticate What is doing the request, but once you release a web app or mobile app into the public any secret on it is now in the public domain, therefore not a secret anymore, as it's best you can use it as a weak identifier.
Web App
A web app runs in the browser, thus all an attacker needs to do is to inspect the page source and extract the secret, and then use it in automated scripts or in manual requests from curl or tools like Postman.
Mobile App
Some developers think that because a mobile app is released as a binary that they can just put the secret there and no one will find it... Well I have to say that in the past I was one of them, but then I came to learn that a lot of open source tools exist to make this task trivial that even a script kid can do it. My preferred tool to do this is the MobSF, and you can see an example of using it in this article I wrote How to Extract an API Key from a Mobile App with Static Binary Analysis:
The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.
MobSF - Mobile Security Framework:
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
The take away is that once an app is released any sensitive information shipped within it must be considered compromised.
JWT and OAUTH2
i have read that JWT with OAuth2 should be used but from my understanding the user have to login into a provider to get the token
Yes, the user would be required to login to get the OAuth token, but any type of token that comes from a user login successfully just identifies Who is in the request, not What is doing the request, and in my experience this is a very common misconception among developers, no matter if they are a junior or a senior developer.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles about Mobile API security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between Who and What is making the reques to your API server:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
You may be surprised that sometimes even your legit users may be the ones attacking your API server in order to try to get benefits from your service that otherwise they wouldn't have access.
SECURING AND LOCKING THE API SERVER TO AN APP
but i want users to be able to read data without login.
my concern right now is how to prevent other people from using my API in their apps
To achieve this requirements in your app you need to find ways to secure and lock your API server to only serve requests from genuine instances of your web and mobile apps.
I have to say that for mobile apps this can be achieved with a very high degree of confidence when a Mobile App Attestation concept is employed, but for web apps we just can do it in a best effort basis, by using Artificial Intelligence solutions.
To understand how you can do it for a web app please read this answer I gave to the question Secure api data from calls out of the app, specifically the section entitled Defending The API Server.
For a mobile app you should read this answer I gave to the question How to secure an API REST for mobile app?, more specifically at the section Securing the API Server and the section A Possible Better Solution.
If you have read both the answers I linked above you may understand now better why I said initially that was a huge challenge.
DoS ATTACKS
u'm concerned also about DoS attacks.
This is not normally addressed at the application level, instead it his best handled at the infrastructure level, like in the Firewall, where rules can be applied to identify and drop DoS packets, but if they are to strict they may also block legit users, while if they are too relaxed they let pass DoS packets. To have more effective DoS attacks protections you need to resort to specialized software, and even this ones may need manual intervention during an huge scale DoS attack.
So my advice here is that you start by adding to the Firewall some rules to drop DoS packets, and/or if you are using a cloud provider you may want to see what level of DoS protection they can offer in your account. I know for example that some CDN providers do offer DoS protection for free until some extent, thus may worth you consider to have all your traffic routed through a CDN, that also brings the other traditional benefits of a CDN, aka serving assets from a closest location to your customers.
DO YOU WANT TO GO THE EXTRA MILE?
In any response to a security question I don't resist to reference the excellent work from the OWASP foundation.
For Web Apps
OWASP Web Top 10 Risks
The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
As part of strengthening session authentication security for a site that I am building, I am trying to compile a list of the best ways to register a user's computer as a second tier of validation - that is in addition to the standard username/password login, of course. Typical ways of registering a user's computer are by setting a cookie and or IP address validation. As prevalent as mobile computing is, IP mapping is less and less a reliable identifier. Security settings and internet security & system optimization software can make it difficult to keep a cookie in place for very long.
Are there any other methods that can be used for establishing a more reliable computer registration that doesn't require the user to add exceptions to the various cookie deleting software?
If you're looking to do device authentication, you may want to consider mutually authenticated SSL. Here, you'd deploy a client identity certificate to each endpoint you'd want to authenticate. Then, you set the server up to require client authentication, so that a client would need to present a valid identity certificate in order to form the SSL tunnel.
This, of course, is not a perfect solution. In reality, this presents much of the same weaknesses as other solutions (to various degrees) Once your client identity certificates go to your clients, they are out of your control; should a client give their certificate to anyone else, you lost the device authentication that you have based on it. SSL identity certificates are generally stored in a keystore on the client which is encrypted with a password or other credential needed to unlock them. While a client certificate could still be compromised, it's somewhat stronger that just a cookie or something like that (assuming you don't have a client that is trying to give away its credential). In addition, you'd want to come up with some validation routine that a client would need to go though in order to get a credential in the first place (how do I know that this is a client device that I want to remember/register?).
Remember, these types of approaches only do device authentication, not users. There are more in-depth schemes already developed for device authentication than what I've mentioned; for example, 802.1x is a network protocol where an endpoint needs to present a client-side certificate to the network switch to get on a LAN. This is out-of-scope for a web application scenario, like what you've described, but the idea is the same (put a cryptographic credential on the client and validate it to establish the connection).
This, like all other security matters really, is a risk decision. What are you trying to accomplish with such a countermeasure? What are the threats you're trying to prevent and what are the consequences if someone does log in on an unregistered device? Only your situation can answer those questions and let you see the real risk, if you need/should mitigate it, and, if so, how strong of a solution do you need to get the risk level down to an acceptable level?
the best ways to register a user's computer as a second tier of
validation
From my point of view this approach does not offer much in the aspect of authentication.
You are not authenticating a user and have no idea who is using the PC that you would accept as being registered.
The way you describe it, this step should be a configuration rule in the firewall to accept connections from specific IPs only.
IMO the filtering of the PCs is the responsibility of a firewall and it would be much better handled by the firewall than any application level filtering.
Just think that you would have the overhead in your application to examine each request and decide whether to accept it or not.
Better leave this preprocessing overhead to the firewall. That's why it is there.
I'm developing a web application (PHP) that may store sensitive/confidential company information and is targeted towards medium to large size businesses.
In developing this application, my team is taking every security measure we can think of, including:
Sanitizing user input for SQL queries (By using the codeigniter input/database libraries)
Forcing the use of HTTPS via HTTP-redirects
Hashing user passwords with the phpass framework (CRYPT_BLOWFISH)
(also checking passwords are < 72 characters to prevent DoS attacks)
Using a database to store session data along with quick session expiration ( < 10min), secure sessions (only sent via HTTPS), and encrypted cookies, and matching IP & User Agent
CSRF (Cross Site Request Forgery) tokens
Using a third party to store and process any credit card data
First, are there any security practices that I may have overlooked? However, my main question is: Are there any reputable auditing bodies/groups/organizations that could audit our application and affirm that we're using the best (or at least industry accepted standard) security measures? We would like to use such an accreditation as a selling-point for our software.
We're developing a REST API to be consumed by a couple of mobile applications. It's important that we're able to trust the identities of these mobile applications. In our current design, each API call is authenticated with an "API Key" parameter and secured with HTTPS.
My concern is that the API Key is embedded within each copy of the mobile app, which means there's no way we can keep it secret. It will be on thousands of phones, and theoretically any hacker with a binary editor or HTTP Traffic analyzer could extract the API key and then 'pose as' one of the applications, sending us requests that we'd have no choice but to trust. Client certificates would appear to have the same risk.
Is there an architecture that solves this problem?
It is being discussed from time to time in different places including StackOverflow. In brief - whatever you put to user's possession is not yours anymore. You can obfuscate the private key, of course, yet I see at least three ways to bypass your security measures.
The only way to solve a problem could be to employ cryptographic device (smartcard or USB cryptotoken) which keeps private and secret keys and doesn't let them out, however with handhelds use of such devices is quite complicated (if not impossible) from both technical and usability points of view.
Also you might want to reconsider your approach and let any client software use the service given that they pay for it. And your server will authenticate users and not software. Then the topic of keeping login data secret will be users' task.
We're working on a site that will make use of the OFX standard to provide access to customer financial data. However, for security we make use of secret question/secret answer, machine tagging, etc. Does the OFX standard provide any mechanisms for security beyond just the simple username/password? I've taken a look at the schema and some sample data, but haven't seen anything that looks like it would fit our needs. Anyone with any experience in this area?
4.1.5 Channel level: Generally transparent to a client or server, channel-level security is built into the communication process, protecting messages between two ends of the “pipe.” To secure messages during HTTP transport, client and server applications use the Secure Sockets Layer (SSL) protocol. SSL transparently protects messages exchanged between the client and the destination Web server. SSL authenticates the destination Web server using the Web server’s certificate. Additionally, it provides privacy via encryption, and SSL-record integrity, i.e. the block of data sent in each transmission cannot be altered without detection.
Application level: Transparent to and independent of the transport process, application-level security protects the user password sent from the client application all the way to the server application that handles the OFX messages. The server application typically resides beyond the destination Web server, secured behind an Internet firewall. Application-level security requires channel-level security.
They have 2 levels of security. You probably would not need more than that. You put in extra security, you would delay sending your financial data. There is ample leverage to check and verify messages with OFX and it probably should suit your application.