Slatedroid info

Everything about android tablet pc [slatedroid]

Good Technology announces expansion of Android security support

Posted by wicked April - 23 - 2015 - Thursday Comments Off

good_technology_logo_square

The focus for Good Technology has been mobile security for nearly twenty years and now the company has a new offering that Android hardware manufacturers can implement with their devices and installed apps. Trusted Execution Environment (TEE) is an interface that secures applications for work that can be accessed through compatible hardware. The access comes from secure key storage through enterprise mobility management that hardware manufacturers are already using today. Good Technology claims that its Good TEE covers everyone involved in an enterprise and end users can forgo the long process of entering password after password.

Good Technology will launch this offering in the form of a beta program next month.

Hit the break for the full press release.

Good Technology Delivers Industry First Hardware-Protected Trusted User Interface and Secure Key Storage for Enterprise Mobility Management

Market-leading secure container solution expands Android device options
and enables more productivity

Sunnyvale, CAApril 21, 2015  ̶̶  Good Technology, the leader in secure mobility, today announced the first Trusted Execution Environment (TEE) and secure key storage for enterprise mobility management (EMM). The Good TEE solution is based on a standard being adopted by Android handset manufacturers that enables hardware key protection for higher security and greater ease of use on a broad range of Android devices. By partnering with cybersecurity expert Intercede, Good is adding hardware backed security capability to all Android Good-secured apps, including Good apps as well as more than 1,600 partner and customer applications developed on the Good Dynamics® Secure Mobility Platform.

“Security and usability don’t have to be a zero-sum game,” said Dr. Nicko van Someren, CTO of Good Technology. With the Good Trusted Execution Environment IT can ease end user requirements, such as allowing much shorter and more memorable PIN codes, without lessening security of corporate data.”

The Good Trusted Execution Environment offers a single solution for a range of Android devices, including personal smartphones and tablets being brought into the enterprise. According to the Good Technology Q4 2014 Mobility Index Report, which tracks secure app and device activations among Good’s 6,200 enterprise customers, Android device activations represented 25 percent of devices activated during the quarter.

The Good TEE enables greater security on a variety of Android devices. Secure container keys cannot be extracted or cracked by “brute-force” attacks even if the device is rooted, and even if the Android OS has been compromised the user’s PIN cannot be intercepted by a malicious app. Decision makers in security-sensitive and regulated markets such as financial services, government and healthcare will find that this layered approach meets the security and usability needs of their increasingly-mobile workforces.

“Good’s leadership in the enterprise mobility management space makes it an ideal partner for our MyTAM Trusted Application Manager service,” said Richard Parris, CEO of Intercede. “By using our over-the-air Trusted Application provisioning service to deliver its secure UI and key-store functions, Good allows IT to have the highest levels of security without compromising ease of use on Android devices.

Trials of Good Technology’s TEE solution will begin in May 2015. Please contact a Good sales representative for more information.

About Good Technology

Good Technology is the leader in secure mobility, delivering solutions across all stages of the mobility lifecycle for enterprises and governments worldwide. Good offers a comprehensive, end-to-end solutions portfolio, consisting of a suite of collaboration applications, a secure mobility platform, mobile device management, unified monitoring, management and analytics, and a third-party application and partner ecosystem. More than 6,200 organizations in 189 countries use Good Technology, and we are trusted and deployed in 100% of the FORTUNE® 100 commercial banks and aerospace and defense firms as well as leaders across healthcare, manufacturing and retail. Learn more at www.good.com.

Statements concerning future prospects, business outlook, and product availability and plans are forward looking statements that involve a number of uncertainties and risks. This information is intended to outline our general product direction and it should not be relied upon in making purchasing decisions. It is not a commitment, promise or legal obligation to deliver any material, code or functionality and the development, release and timing of any features or functionality described for our products remains at Good’s sole discretion.

©2015 Good Technology Corporation and its related entities. All use is subject to license terms posted at www.good.com/legal. All rights reserved. GOOD, GOOD TECHNOLOGY, the GOOD logo, GOOD FOR ENTERPRISE, GOOD FOR GOVERNMENT, GOOD FOR YOU, GOOD APPCENTRAL, GOOD DYNAMICS, SECURED BY GOOD, GOOD MOBILE MANAGER, GOOD CONNECT, GOOD CONNECTED CONTAINER, GOOD SHARE, GOOD TRUST, GOOD VAULT, and GOOD DYNAMICS APPKINETICS are trademarks of Good Technology Corporation and its related entities. All third-party trademarks, trade names, or service marks may be claimed as the property of their respective owners. Good’s technology and products are protected by issued and pending U.S. and foreign patents.

Come comment on this article: Good Technology announces expansion of Android security support

Should we be worried about Android app permissions?

Posted by wicked April - 10 - 2015 - Friday Comments Off

facebook permissions

If you’re really honest, do you actually read the permissions that Android apps are asking for before you install them? If you do, then there’s little doubt that you’re in the minority. Most of us treat them like terms and conditions, blindly clicking, or tapping, our way through. Is this something we should be taking more seriously? What are we actually giving away here?

Developers are well aware that most people don’t pay much attention to permissions and a lot of them have been surreptitiously adding more and more permissions to the list. Take a look at this chart of permissions for some of the most popular apps and games around.

Do these apps really need all these permissions? If you dig into the list, which you can find via the View details link under Permissions on the Play Store page for each app, then you’ll find some pretty puzzling requests.

The popular game Cut the Rope, for example, requests permission for your Location and yet the Privacy Policy from developer, ZeptoLab, specifically states “Geo-Location Data. ZeptoLab does not ask you for, access, or track any location based information at any time while downloading or using ZeptoLab’s mobile applications or services.”

I emailed and asked about it and here’s what Community Manager, Olga Antsiferova told me,

“Location data is needed for advertising SDKs to show people the ads which are relevant to their country. It is also used in both free and paid version of our games to identify countries with COPPA law. Finally, it is used in analytics, but it is important to understand that we gather only general, not personified info (i.e. “today we received 10k downloads from UK”) and we do not track individual devices.”

I’m not singling Cut the Rope out for any particular reason, by the way. You could pick an app at random and probably find a permission that’s puzzling at first glance.

What’s the problem?

A spotlight, or flashlight, was thrown on the issue a while back when popular free app Brightest Flashlight turned out to be selling location data and device ID information to third party advertisers. It transpired that it was far from the only app engaging in a fire sale of our personal data. A lot of flashlight apps are asking for permissions they absolutely do not need to function. It’s not a phenomenon that’s restricted to flashlight apps.

flashlight apps permissions chart

In all likelihood what we’re talking about here is the sale of anonymized data to advertisers, so that developers can generate a little extra cash. Some of you might be okay with that. But you’re actually putting a lot of trust in these developers. It’s one thing to trust that Google isn’t going to do anything untoward with your personal data (and some people struggle with that idea), but how much do you know about the publishers and developers behind the apps you’re using, or the third-party advertising networks that they work with?

Is there a worse scenario? Are you giving them the permission to do things like upload all your personal photos to a web server or sell your contacts list? While it may be technically possible in some instances, it’s extremely unlikely that they’re actually doing that, it’s illegal and they wouldn’t get away with it for long. The most likely explanation is generally innocuous — an app might want access to your photos to allow you to upload an image directly in the app without having to jump through hoops or quit the app and start up the gallery app.

The problem is that most people don’t really know what the permissions mean, they aren’t willing to research it, and they don’t want to have to. What they really want is to be able to trust that someone else is looking out for them.

Google does have your back, up to a point

The Play Store is pretty secure. Google does a lot of work behind the scenes to make sure that the apps on offer are safe. Most of the scaremongering about malware on Android is designed to sell security apps. If you only ever download apps from the Play Store with high numbers of downloads and a good review score, and you don’t tick the Unknown sources box in Settings > Security then you realistically have nothing serious to worry about.

google verify apps defense (2) Quartz

The trouble kicks in if you’re concerned about privacy. If you don’t like the idea of giving strangers potential access to a lot of personal data. If you don’t like the idea of them collecting information about your habits. There’s a gray area of acceptability there that Google isn’t policing.

Your only real option if you don’t like the permissions that an app is requesting is to not install it. But, why is that the case?

Puzzling changes

Google simplified app permissions last summer (some people will say dumbed down) and things are grouped into sections now. This was supposed to make it easier for people, but it actually makes it tougher to see what specific permissions you are granting. It also means that an app can request a new permission in an update and if you’ve already granted a permission in that section it’s automatically granted without your say-so.

We need better control over permissions

There are a lot of other ways this could work. You could be asked for a permission when an app actually needs to use it, but this could arguably impair the user experience. You could also have a clear menu where you can go in and deny specific permissions, or tell the app to ask when it needs that permission. Something like App Ops which Google rolled out and then retracted.

Google brought App Ops out in Android 4.3, though it was never advertised. It was quietly removed in Android 4.4.2. It allowed you to revoke specific permissions for apps. Officially Google claimed it was only ever intended for developers. It’s possible part of the reason it was removed was to prevent stability issues for apps if users started revoking permissions all over the place, but realistically it probably had a lot more to do with advertising revenue. If you could use free apps and easily block permissions that generate ads (and revenue for the developers) then you probably would, right? That could make Android app development unprofitable for many.

What can you do?

The bottom line is that most developers are asking for permissions because of some function or feature in the app and the request is legitimate. There’s another tier of apps that are trying to turn a profit by selling anonymized data. Unfortunately it’s not always easy for the average person to tell the difference. If you’re concerned, then make sure you read the permissions and the privacy policy. There’s no substitute for doing a little digging to see what you can uncover. If you routinely download apps from outside the Play Store then you really can’t afford to ignore permissions.

You can find a bunch of permission managers in the Play Store, many confusingly called App Ops or some variant. If you’re rooted then check out X Privacy Installer for smart protection that won’t make the apps fail.

Tell us what you think. Do you read app permissions before every install? Are you worried about leaking personal info? Do you care about anonymized data for advertisers? Is Google doing enough to protect our privacy?

Lollipop arrives on Sprint for Galaxy Note 3 and Galaxy Note Edge

Posted by wicked April - 9 - 2015 - Thursday Comments Off

sprint_logo

If you’re a Sprint customer and own a Samsung Galaxy Note 3 and/or Galaxy Note Edge, your wait for Lollipop is over! This update will bring you to Android 5.0 and not 5.1, though.

This update is arriving over-the-air (OTA) starting immediately. Be advised, Sprint has already stated that this update will be coming in stages over the next few days, so if you don’t have it right this second, keep checking for it!

The update is also bringing WiFi calling enhancements and Factory Reset Protection to the Note Edge only.

Source: Sprint Samsung Galaxy Note 3 and Sprint Samsung Galaxy Note Edge

Come comment on this article: Lollipop arrives on Sprint for Galaxy Note 3 and Galaxy Note Edge

Android Security report card and the scanning of devices

Posted by wicked April - 3 - 2015 - Friday Comments Off

Let’s face it. As much as we love Android, it hasn’t exactly been the most secure mobile platform on the planet. Sure, nothing is exactly and perfectly secure, even the walled garden that is iOS but Android has been notorious for making things a little bit easier for miscreants. Of course, that only means that Google has to work incessantly on security and keep vigil over its territory and, today, it’s giving itself a pat on the back for a job well done in 2014.

Majority of the security problems on Android can be traced back to malware, almost all of which masquerade as legit apps. It stands to reason then, that rooting out and blocking these apps are key to cutting off the spread of malware. Aside from regularly scanning Google Play Store itself, Google also scans apps during and after installation on a device. This is made possible by Android’s “Verify Apps” feature which, in theory, warns and blocks apps that it deems to be harmful, or what Google calls “Potentially Harmful Apps” or PHAs.

But Verify Apps is only half the story and only scans apps that are installed via Google Play Store. Considering there are other app markets out there, plus the ability to install APKs directly, Android needs a safety net to fall back on. Quite appropriately, Google calls this feature “Safety Net”. Like Verify Apps, Safety Net looks for PHAs on your device, regardless of whether they came from Google Play Store, F-Droid, or APKs. It does so by scanning the device itself at regular intervals, by default at least once per week, to root out would be problems, both in apps as well as network attacks.

verify-apps-chart

Now, contrary to normal reaction to this device scanning procedure, there is little reason to start becoming paranoid about Google intruding on your privacy. At least, depending on how much trust you ascribe to the Android maker. Google claims that it only scans enough information to ascertain the security of the device and nothing more. It neither scans personal information or even location, though it does try to detect the locale (language) of the device to see if there is anything amiss.

And it seems to have worked! Google boasts of a few of its achievements in the security arena last year. Of course, these are numbers from Google itself, so its up to you how much salt you will take with it. Of the over 1 billion devices that are protected by Android’s security system, only 1 percent had a PHA. That number is even lower, down to 0.15 percent when you consider only those that actually install from Google Play Store and thus utilize the Verify Apps security feature. The rate of actual PHAs that got installed went down considerably down to 50 percent between the first and last quarter of 2014.

Those are definitely impressive and encouraging numbers, but some might be fixated on the fact that Google is scanning their device regularly, even for a worthy cause. Fortunately, Google lets you shoot yourself on the foot and disable this security checks yourself. On most devices, you can navigate through the phone’s Settings, drill down to the Security section and disable the Verify apps features. On Nexus devices, particularly those already on Android Lollipop, the same setting could be found inside the separate Google Settings app instead. Of course, if you do so, be aware that you are practically on your own when it comes to security your phone as well as your data.

verify-apps

SOURCE: Google

Protect your privacy with VPN by Private Internet Access

Posted by wicked April - 3 - 2015 - Friday Comments Off

SPONSORED CONTENT


VPN by Private Internet Access is a simple, but effective VPN service that you can use to make yourself anonymous online, keep you safe in public WiFi hotspots, and perform any other sensitive business like financial transactions, file transfers or anything else that you would like to keep secure online. The application is free in the Google Play Store and you must sign up for a subscription before being able to enjoy the service.

VPN by Private Internet Access

How does it work?

VPN stands for virtual private networks. What they do is essentially create a private network that only you can join. That private network then connects to public networks like your local coffee shop or airport WiFi. This added layer prevents hackers and internet service providers (ISPs) from seeing what you’re actually doing on the web. These are essential tools for those who value their online privacy and VPN by Private Internet Access provides that functionality.

The app itself is simple and effective. You have to create an account before starting and subscribe to one of their plans (which are either monthly or yearly based on your needs). Once you sign in, you can connect to servers all over the world. VPN by Private Internet Access also includes IP cloaking which allows you to circumvent blocked content (for you folks who live in countries where this is a problem).

In addition to the standard VPN services and IP Cloaking, VPN by Private Internet Access also uses a compression algorithm in the app. This can save your data if the sites you go to can be compressed (which makes them smaller) and can even make your web browsing a little bit faster depending on your connection.

The Android client is based on OpenVPN which is one of the more trusted systems to work with. With a basic subscription, you can also connect up to five devices simultaneously and the app has cross platform support. That means one subscription can cover your Android phone, Android tablet, Windows or Mac computers, Ubuntu, or iOS devices with just one subscription.

You’ll also have access to over 3,000 servers in 15 countries and over 25 regions.

VPN by Private Internet Access

The Pros

Here’s what we liked about VPN by Private Internet Access.

  • They use OpenVPN for their Android application which is one of the best systems to use.
  • According to their FAQ, they do not keep logs. Ever.
  • The subscription service covers five devices so your Android phone and Android tablet can be covered.
  • IP Cloaking and data compression are both seriously awesome features.
  • There are some customization settings like turning on the VPN service when you boot automatically along with some more advanced configuration options.
  • Cross platform support means that you can also use that five device subscription coverage on computers and iOS devices, including iPads, Macs, computers running Ubuntu, or Windows.
  • Comparatively speaking, the VPN service is reasonably priced.

The bad

And here’s what we didn’t like so much:

  • The interface is a bit bland. It gets the job done to be sure and it’s easy to figure out, but it’s not much to look at. Thankfully you only have to use it to turn it on.
  • We would’ve liked a free demo. You can get one, however. VPN by Private Internet Access appears to have a 7-day money back guarantee. You have to pay up front but if you don’t like it, let them know within a week and you should get a full refund.
  • VPNs in general can be a bit finicky on Android. This isn’t the fault of the application, but sometimes things do go wrong specifically with VPNs.

VPN by Private Internet Access

Overall

Overall, VPN by Private Internet Access is a solid and well done VPN service. The lack of logs, IP cloaking, and data compression are all great reasons to give it a shot. Subscriptions covering five devices is icing on the cake as well and VPN by Private Internet Access has one of the more simple payment plan structures of any VPN app which is nice for simplicity’s sake. If you want to give it a shot, check out their official website and download the application using the button below.
Get it on Google Play

 

SPONSORED CONTENT

Android malware installs decreased by nearly 50% in 2014, says Google

Posted by wicked April - 2 - 2015 - Thursday Comments Off

Google Logo AA

Security isn’t to be taken lightly, especially when it comes to dealing with sensitive consumer information. To shed some light on its recent efforts, Google released a whitepaper earlier today that explains what exactly the Android security team has been working on in the past year. The report, titled Android Security State of the Union, analyzes billions of data points gathered throughout 2014 that detail the current state of Android security.

The full report is quite lengthy, but there are a few main points Google would like to highlight. For starters, the company says the worldwide rate of Android malware installs decreased by nearly 50% throughout 2014. And over the entire year, fewer than 1% of all Android devices contained any type of harmful application at all. Of the devices that only installed applications from the Google Play Store, fewer than .15% contained a harmful app.

In addition, the company explains that over 1 billion devices are protected by its Verify Apps service, which now scans over 200 million devices per day. Lastly, the Android team and all affiliates responded to 79 externally reported security issues overall, and over 25,000 applications in the Play Store were updated following security notifications from Google.

Now, all of these numbers Google has laid to us out are quite broad, especially given the company’s meaning of the word malware (or Potentially Harmful Apps). But if you are interested in getting some more information on specifics, Google has detailed everything in a very lengthy report, which you can find here.

Google has already made clear its intentions to focus more on reviewing policy violations in Google Play in hopes to reduce malware even further over the next year. Even though many users are still concerned with Android security, the company hopes this new report will bring those worries to an end.

Android malware was cut by 50 percent in 2014

Posted by wicked April - 2 - 2015 - Thursday Comments Off

Android_Malware_Bugdroid_01

Google’s crackdown on malware has been working, at least according to them. In a new Android Security Report, Google says that the global rate of malware installs fell by 50 percent in 2014.

According to Google, only 1 percent of all Android devices had a harmful application in 2014. There’s even better news for those that only install applications from the Play Store as that number drops to .15 percent.

Google also provided device manufacturers with 79 security patches, and improved their abilities in responding to potential vulnerabilities. 73 of these patches have been released to AOSP, while the remaining 6 will get released with next AOSP update.

Google’s report is 44 pages and includes more information about the vulnerabilities, malware, and more. You will find it in the source link below.

source: Android Security 2014 Year in Review
via: The Verge

Come comment on this article: Android malware was cut by 50 percent in 2014

Where is the best place to store a password in your Android app

Posted by wicked March - 31 - 2015 - Tuesday Comments Off

Security concept

Typically Android security issues fall into a couple of major categories. Firstly, personal information stored insecurely on a phone and secondly, insecure communication to any back end database or web server.  And while there are lots of other things that can go wrong, the majority of security problems fall into these two areas. In this article we will look at the various options available to secure personal information  in an app, and in the next article we’ll look at network communications.

The best option is to never store a user’s personal information, such as passwords or credit card numbers, on the phone. If getting the user to enter a password each time is not an option then you’re going to have to store the username and password somewhere on the device. There really aren’t a lot of places you can store information on an Android device. The possibilities are to store the information in shared preferences, or in a sqlite database, or in the device’s keystore.

Over the past few years, I have been part of a process that manually audited a couple hundred Android apps. During that time I have seen the same security problems, repeated again and again. And although we do our best to let the developers know about the security issues with their apps, we’ve been a lot more successful at hacking the apps than at getting anyone to fix them.  So in an effort to spread the knowledge, let’s look at some real world authentication patterns we’ve seen as developers try to hide password information.

These are ranked in order of difficulty to break.

  1. Store in cleartext
  2. Store encrypted using a symmetric key
  3. Using the Android Keystore
  4. Store encrypted using asymmetric keys

Cleartext

Plaintext encryption

Using cleartext means there is no protection to a user’s runtime data – assuming the hacker has physical access to the phone, which is a big assumption. But as there are so many phones for sale on eBay and Craigslist you have to assume that your app is going to end up sooner or later on a secondhand device.  You can access all the information in an app’s data folders use the adb backup command and then convert it into a tar format using the Android Backup Extractor or abe.jar. For example:

adb backup com.packagename.android
java -jar abe.jar unpack backup.ab
tar -xvf backup.tar

Using cleartext means there is no protection to a user’s runtime data – assuming the hacker has physical access to the phone.

A slightly better option used by a significant number of apps is to set the android:allowBackup flag to false in AndroidManifest.xml and then put whatever you want in the shared preferences or in into an sqlite database. The idea being that if nobody can back it up then nobody should be able to access the passwords. Unfortunately there’s a big flaw in this argument. Android is a Linux based system so root will have access to any files on the phone. If the phone isn’t properly wiped when it’s resold the new owner is going to have all the time in the world to root the phone and recover whatever dynamic user information is stored in the data folders by changing the permissions on the file and then doing an adb pull, instead of the adb backup command. Here is an example shared preferences file with an exposed password:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<string name="password">2secret4me</string>
<boolean name="remember" value="true" />
<string name="username">androidauthority</string>
</map>

Symmetric Encryption

Symmetric Encryption

A much better idea is to encrypt the password before you store it. If you are going to take this approach then don’t store the key in the APK code or anywhere else on the phone. It’s never a good idea to use AES, DES or any other symmetric encryption algorithm if you store the key where it can be easily found.  It is a relatively simple process to find the APK and then get a copy off the phone. The command adb shell pm list packages will get a list of the APK’s on your phone. To find where the APK lives on the phone use the command adb shell pm path com.packagename.android using your APK name. Then use the following command to get a copy of the APK, adb pull /data/app/com.packagename.android-1/base.apk making the appropriate changes for the package name and path or apk name where appropriate.

Use jadx base.apk to decompile the code back into java source code to see if you can find the encryption key in the code. If you are familiar with dex2jar then I suggest switching to jadx. It is an order of magnitude better at decompilation than dex2jar. Lots of apps I audited in the past with dex2jar have only given up their secrets when we starting using jadx.

Developers are a helpful bunch and they often put the encryption keys in easy to find places like com.packagename.android.util.security.

Developers are a helpful bunch and they often put the encryption keys in easy to find places like com.packagename.android.util.security. If that doesn’t work more often than not the code isn’t obfuscated and you can try searching for the class name or phrases like ‘encrypt’ or ‘decrypt’.  To decrypt the password cut and paste the decryption code into a java file and give it the password as an argument.  Some developers make the encryption key device specific by including device information such as the AndroidID as well as make and model information, but it’s mostly worthless if you can already see how the key is put together in the code. If you are going to use some sort of a recipe to generate the encryption key then obfuscate the code properly so that the ingredients are not easy to find. If possible store some piece of information (or even the entire key) remotely on a server, so not all the information can be found on the phone.

And as your app grows and you add more developers, make sure everyone knows how to encrypt and decrypt login information. In one of the dating apps I audited, I found the password encrypted in the shared preferences and another copy of the password was also stored in cleartext in the app’s sqlite database. Someone either didn’t know the rules or simply forgot to remove old code that stored the password in the database.

If you’re writing a healthcare app and you want to see if it’s HIPAA secure then put your device into airplane mode and if you can still log into the app then it’s probably not compliant with the HIPAA regulations.

Android Keystore

The safest option for encrypting passwords is to use asymmetric encryption algorithms such as RSA. Asymmetric means that the key is split into public and private keys where only the private key can decrypt the information.  We’re seeing a lot more developers using the Android Keystore to store public and private asymmetric key information.

old_keys

In the Android Keystore this public – private key exchange takes place on the device and would seem to be HIPAA compliant. We say ‘seem to be’ as once again if you can root the phone you can gain access to the private keys. Nothing is 100% secure and sooner or later someone will find a way to get at the keys, especially if you put everything in the same place.  I’ve always had a problem with mechanisms like the Android Keystore because app developer’s are relying on the skills of another developer for security, and there is no physical impediment to get at the keys.

Android Keystore public and private keys are stored in the /data/misc/keystore/user_0 directory.  The private key is stored in a file that has <app_id>_USRCERT_<key_alias>.  On a rooted phone you can copy the file to another <app_id_malicious>_USRCERT_<key_alias> and then import it from your malicious app, allowing you to recover the password.

Asymmetric Encryption

A safer asymmetric encryption option is to store the private key remotely. When the password is first entered, it is sent to the server for storage. It’s also encrypted with the public key and stored in the shared preferences.  Every time the password needs to be checked then the public key encrypted password gets sent to the backend server and decrypted by the private key. It is then checked against the password information in the server’s database.  A token is then passed to the Android client to allow access to the app.  At no time is the password visible on the phone.

In Android this usually means using the Spongy Castle libraries or other alternative such as Google’s Keyczar.  Sure there are other security issues that you have to think about like how to ensure that someone isn’t just sending you a publically encrypted key from a different device. But it is a lot easier to add extra ingredients to your asymmetric key recipe to foil these type of attacks when the code is on the server.  We’ll return to this in the next article.

In the future Lollipop device encryption may put an end to many of these types of attack, but until Lollipop gains critical mass then options 1, 2 and 3 are not secure approaches. Our original recommendation is to ask the user to enter their password every time they sign in. If that’s not possible then never store the password in cleartext or leave the key in the code or on the device for someone to find.  Asymmetric encryption keys using Spongy Castle or Google Keyczar are much better alternatives to consider.  In the next article we’ll look at similar options for safeguarding your API keys.

Subscribe to our Android Developer Newsletter
Join our Android Developers newsletter to get all the top developer news, tips & links once a week in your inbox


About the author

Godfrey NolanGodfrey Nolan is the founder and president of the mobile and web development company RIIS LLC based in Troy, Michigan, and Belfast, Northern Ireland.He has had a healthy obsession with reverse engineering bytecode. See more from him here. He’s also the author of Bulletproof Android: Practical Advice for Building Secure Apps.

 

Samsung to Partner with SRI to Make Devices with Iris Recognition

Posted by wicked March - 27 - 2015 - Friday Comments Off

One popular trope in science fiction films is the high-level security clearance requiring iris scanning. By the end of this year, not only will that feature no longer be science fiction, it will be mobile! That’s right—as if fingerprint scanning wasn’t neat enough, SRI (Stanford Research Institute) is now working with South Korean tech giant Samsung to manufacture a mobile device that will feature iris scanning technology.

The device will be a customized version of the Samsung Galaxy Tab Pro 8.4 and will feature technology that is shown to be 1,000 times more accurate than fingerprint scanning technology. You can expect to see it at ISC West 2015, followed by a worldwide release.

What do you think? Is IOM (Iris On the Move) technology the future, or just another gimmick? Leave a comment below and let us into your mind!

Source: SRI

Via: Android Central

Come comment on this article: Samsung to Partner with SRI to Make Devices with Iris Recognition

Users reporting new “On Body Detection” lock mode in Android

Posted by wicked March - 22 - 2015 - Sunday Comments Off

on_body_detection_01

Based on reports starting to be made by users, Google is either testing or slowly rolling out a new lock mode for Android devices designed to detect when a device is physically in a user’s possession. The lock mode, called “On Body Detection” uses a device’s sensors to detect whether a device is being held in a person’s hand or is in their pocket and will keep the device unlocked. If the device is set on a table or something similar, the device will lock, requiring a user to employ their normal unlock method.

The new method appears to have been designed to help thwart thieves in case a user accidentally forgets their device somewhere. One thing users have determined is that the on body detection feature will not lock a device if the device is handed to someone else, so it is not tied to a specific user – only movement typically of being on a person’s body or in their hand.

Google has not announced anything about the mode, but it appears to be included in the most recent recent Play Services update. Thus far, only users with devices running at least Android 5.0 or higher have the new mode available, so it looks like it may be a Lollipop-only mode.

on_body_detection_02
on_body_detection

source: Android Police

Come comment on this article: Users reporting new “On Body Detection” lock mode in Android