Tag Archives: android

Guest Post: Protecting Your Account When Using Mobile Banking

payments, smartphone, , , ,

Phone with key“In the world of online transactions, it can be easy for money to be stolen”

 

 

The security of your finances is everything to you. To ensure that your money stays your money and that your account information is kept safe, consider the following tips:

Passwords, along with security setting options, are your controllable lines of defence for mobile banking safety. It is always a good idea to have a password lock on your phone to make for more complicated access for potential thieves. If your phone becomes stolen, report it to your bank right away. The password lock on your phone can act to slow down a thief’s ability to obtain information.

Adjust your settings so that you can only enter an incorrect password a maximum of 3 times. Don’t be tempted to save a paper or virtual trail of your password or account information – the idea is to be as discreet as possible.

Avoid creating and using passwords that involve the name or birthday of a significant other, child or pet. It is not a good idea to use last digits of your social security number in your password either. Substitute letters for symbols and have random uppercase letters in the middle of your password – it will make the whole process of hacking more complicated.

Avoid using the same password for different sites. It may be more difficult to hack a bank website, but if you use the same simple, or weak, password for a variety of websites, a hacker can go to a not-so-heavily protected website, such as a low-key shopping website, and quickly gather your information through that site. The hacker can then use that information to access your bank account via a Brute Force Attack, which is a software used specifically to log into a site using your information.

For another level of protection, it would be a good idea to change your password every now and then too for added security. The stronger and longer the password – meaning, the more complex the password – the more difficult it is for hackers to obtain your credentials.

Constantly review bank statements to ensure that everything is in proper order. That way, if numbers are out of line, you can contact your bank immediately about the misalignments.

Be cautious of solicitations claiming to come from your bank asking for account information, which is an act known as “phishing” or “fishing”. Instead of providing the information via that link, opt to go to your banking website directly to enter in the requested information and to check the legitimacy of the solicitation.

Do not connect to your bank account via public Wi-Fi. It is not secure as you think and other people can access your information.

Log out of your account – don’t keep it continually signed in and don’t set it to automatically log in. Doing so will make it simpler for people to access your information from malware attacks. Furthermore, consider installing a mobile antivirus device onto your phone for added protection.

If your bank has an app, make sure it is a verified official app. With mobile banking, it is important to recognize the need for safekeeping of your phone – avoid leaving it unattended.

Mobile Banking is definitely convenient. It can also be safe if your take the precautionary steps to ensure your personal information stays private.

Marcela De Vivo is a freelance writer from the Los Angeles area who writes on everything from mobile security and software, to holistic medicine and supplements. As a business owner, protecting her bank information is highly important, and she takes extreme caution when it comes to accessing her finances.

Security News Roundup: Can You Hear Me Now?

news, , , , , , ,

Sometimes, the price of success is unwanted attention. Witness the apparently stratospheric rise in malware on the Android mobile platform. With mobile usage continuing to explode, coupled with the vast array of valuable data we store and access from our phones, it should come as no surprise that the  bad guys want a piece of the action.

Why does Android seem prone to these issues? Part of the answer lies not in the technology, but in the end user. Hacking the human mind continues to yield some rich pickings. Disappointingly, we just keep clicking on stuff without thinking. Where’s the patch for that?

We can’t help recalling the uproar a few years ago when “free” webmail services were all the rage. The big deal then was the realisation that these providers could actually read your mail. The very thought! Roll forward to the present day, and not only have we completely forgotten about that, we’re storing all sorts of data in all sorts of places, without a care in the world.

Lost or stolen USB keys, DVDs and  laptops were also big deal, but now that’s all passé.  Now we have an even better way to lose sensitive data that we shouldn’t even be storing in the first place. Yes, it’s bring your own cloud, the thoroughly modern approach to data storage that has done for data security what King Henry VIII did for gender equality.

Emails aren’t secure, data is at risk of compromise more or less all the time. What’s left?  The good old cellphone system. That’s probably secure. By “probably”, of course we mean “probably not”. Witness this post via Bruce Schneier highlighting the techniques used by the FBI in order to intercept phone data and track users. Very informative.

But is it controversial? An organisation that tracks your location, knows all your contacts, reads your emails and extracts data from your phone? This is, of course,  completely unheard of on the Internet. On a mobile phone. We’re sure you see our point here.

Let’s end with a summary. We’re using mobile platforms that are full of holes, to store data that we shouldn’t be storing, on cloud services that are insecure; whilst assorted governments, commercial organisations and bad guys all compete for access to that data, right in the palm of our hands.

Who says information security is boring?

Which Applications Are Eligible for PA DSS?

mobile, pa dss, smartphone, , , , , , ,

Print

If you can answer “yes” to any of the following questions, then your application is not eligible for validation under PA DSS 

  1. Is this a beta version of the application?
  2. Does the application handle cardholder data, but the application itself does not facilitate authorization or settlement?
  3. Does the application facilitate authorization or settlement, but has no access to cardholder data or sensitive authentication data?
  4. Does the application require source code customization or significant configuration by the customer (as opposed to being sold and installed “off the shelf”) such that the changes impact one or more PA-DSS requirements?
  5. Is the application a back-office system that stores cardholder data but does not facilitate authorization or settlement of credit card transactions? For example Reporting and CRM, or Rewards or fraud scoring
  6. Is the application developed in-house and only used by the company that developed the application?
  7. Is the application developed and sold to a single customer for the sole use of that customer?
  8. Does the application function as a shared library (such as a DLL) that must be implemented with another software component in order to function, but that is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software components?
  9. Does the application depend on other software in order to meet one or more PA-DSS requirements, but is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software?
  10. Is the application a single module that is not submitted as part of a suite, and that does not facilitate authorization or settlement on its own?
  11. Is the application offered only as software as a service (SAAS) that is not sold, distributed, or licensed to third parties?
  12. Is the application an operating system, database or platform; even one that may store, process, or transmit cardholder data?
  13. Does the application operate on any consumer electronic handheld device (e.g., smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing?

Remember that even if your application is not eligible for assessment under PA DSS, it may still be required to operate in a PCI compliant fashion. Speak with your QSA for further advice.

Point 13 above is expanded upon in the SSC document “Mobile Payment Acceptance FAQ“, where the different categories of mobile payment acceptance applications are detailed.

The above information is taken from the full PCI SSC guidance note available from here.