LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityPassword storage on Android devicesA number of Android device owners are upset to learn that their trusty products store sensitive credentials — such as email account passwords — in plain text. The bug tracker entry has amassed an impressive number of votes, but as the attached discussion reveals, any proposed solution butts up against consumers' conflicting expectations — such as that the device continue to check for messages as long as it is turned on, yet never inconvenience the user by demanding a password. The root of the trouble is that POP, SMTP, IMAP, and other email protocols may require the client to provide the account password on every connection attempt. Thus, in order for the phone to check email silently in the background, the OS must have access to the password in plaintext. Google's default email application does just this, storing account passwords in the clear inside a SQLite database. Google's Gmail-specific client application, which uses a different, token-based authentication protocol, does not require the password on each connection, but the token itself may serve just as well. Discovery of that password "flaw" spawned a tremendous public outcry in the comments section of Android bug #10809. Of course, Android is not alone in this regard. Apple's iOS and other mobile platforms also store passwords on the device in plain text, and a client application on any other computing platform faces the same challenge: Thunderbird, PINE, Evolution, KMail, etc. — even IM clients — all send the account password to the server when left running unattended. Consequently, they must either store the password in plain text, ask for it on every connection attempt, or encrypt it and require the user to enter a different passphrase to unlock the storage location. Analyzing the problemThe difference is that mobile phone users are unaccustomed to logging into their phones with a username and password, and even if they do, they tend to leave their phones on (and thus leave themselves "logged in") 24 hours a day. A password store decrypted at login time would be readily available to a pickpocket, even if it is stored securely when the phone is deactivated. The pickpocket attack reveals another challenge to mobile password security: there is a difference between security measures that protect user credentials on "disk" when the phone is off, and measures that protect the credentials during an active session. Android will be implementing its own form of full-disk encryption with 3.0 ("Honeycomb"), which will offer protection against extracting information from the flash storage card. But this will not help any users on earlier versions of Android, nor does it protect against attackers who steal running phones. Google cannot force third-party application developers to store passwords wisely, but many commenters on bug 10809 feel that the company ought to provide a more secure option for the set of default Android applications. The discussions on the bug tracker and on external sites like Android Central make for interesting reading. Some suggested encrypting (or obfuscating) the password file itself, and storing the key to that file elsewhere, such as on a "keychain" stored on the device. But as Android developer Andy Stadler pointed out, this does not improve security, it only moves the weak link to a different file. The password safe must be decrypted for the application to use it, which means the password to the password safe must itself be stored in plain text for unattended access. As he put it, there is "a simple test: if you can boot up the device and it will begin receiving email on your configured accounts, then the passwords are not truly secure. They are either obfuscated, or encrypted with another key stored somewhere else." Others suggested not storing the passwords locally at all, but storing only a hash of the password instead. This approach does not work either, as user hyperhacker noted, because hash functions are one-way, and the original password is what must be sent to the server. Thus in practice either the user will be prompted for the password to validate the hash value (in which case the stored hash is clearly useless), or else the "hash" function is actually an encryption function, and the scheme is no different from the other encrypt-the-password-file proposals mentioned above. Inconvenient securityThe "executive summary" of the situation is that either the OS has access to a password in plaintext without user intervention, or else the user must be prompted to supply a password that is stored nowhere on the device. The real question is how much inconvenience the user will tolerate. A scheme that asks the user for a boot-time passphrase to unlock a password safe is not very secure because of how long phone sessions typically last. As user mahashel put it in a related bug report:
The trick with phones is that they are powered on for great lengths of
time. Once the User logs into the device the filesystem is
visible/decrypted, and it remains that way until powered down. How may
people power down their phones before they lose them? ;)
One alternative would be to re-prompt the user for a passphrase whenever the device is awakened from an idle or sleep state. User aigarius argued that this would prevent the device from checking email in the background. "If you 'tie' it to the unlock code, then you can only check the email when the phone is unlocked, which is clearly quite useless." This is not true in the strictest sense: the OS could "forget" the password only when the user begins the unlock procedure — that way the background process could continue to check messages and activate alerts, and a pickpocket would still be locked out — but it still requires the user to enter a passphrase, PIN code, gesture, or some other form of credential every time he or she picks up the phone to do anything. That level of inconvenience seems to be anathema to most consumers. User solinym suggested biometrics might be better received among consumers than passwords, with a caveat: "If you think key rotation is a PITA, you haven't tried replacing your fingerprints." He also raised the question of hardware security, tamper-resistance in particular, suggesting that the hardware required to prevent hardware key-extraction would add little to the cost of modern smartphones. Gertvdb suggested storing a "master password" on the phone's SIM card, because SIM cards are more secure by default, they limit the number of attempts to enter the PIN code, and they have storage capacity. "The phonebook / SIM SMS message store should have enough space, even on 8k SIM cards. (And doesn't seem to be used by Android) (Some compression might make sense, to reduce the amount of storage needed)." Of course, not all phones use SIM cards, and on those that do, denial-of-service is a risk, as an attacker (perhaps a casual one just snooping around) could exceed the allowed number of PIN guesses and lock out the phone owner, even if they do not gain access to the data on the device. As is typical of security debates, the talk returned time and time again to whether or not providing some form of weak security was worthwhile (to prevent casual attackers), or whether, in the absence of a foolproof solution, all other solutions give users a "false sense of security" and are "a complete waste of time" for developers to attempt. Eventually a number of suggestions arose that amount to offering user-selectable "security levels," through which security-conscious users could enable strong encryption of their credentials at the cost of automated access, and the more laissez-faire could dispense with it. User danthanos called for a public API providing a secure storage service:
This service could be offered as an API to any Android app including the
mail application. In future this API could make automatic use of any h/w
based secure storage for key materials and credentials. Most of the
fundamental crypto methods and needed software libraries exist to implement
a service of this nature.
Tangential issuesGoogle has not responded with a game plan. Stadler, who marked the bug as "medium" importance last September, also commented "rest assured, I am not closing this bug. We recognize that this is causing concern for some users, and we're going to look at identifying steps that can make your data more secure" — which remains the last public word on the subject from the Android team. The full-disk encryption debuting in Honeycomb is unquestionably a step in the right direction, because it does offer protection against exposing one's password in the event of a memory card theft. Intriguingly enough, however, another commenter reported that Android already has an internal "Credential Storage" API that is not documented for public use. Several third-party Android discussion forums have also brought up this API, so it appears to be in the wild already, but there is no official discussion of it. It appears to be used by applications for storing VPN certificates and other credentials not chosen by the user, but without a published API it is not likely to be useful to developers (and abusing it may break important things as well). Android does have a "remote wipe" function (as asked about by hyperhacker in the bug discussion thread) for administrators to activate in case of theft, although it must be set up in advance. Needless to say, a remote wipe is hit-or-miss: if activated before an attacker accesses the phone, it works, if activated afterward it does no good at all. Remote wipe can also be used in ways that users may not expect. In the meantime, security-focused users and developers can always turn towards third-party Android Market tools to offer additional layers of protection. There are stand-alone applications for bulk password storage, although these do not automatically sign-in to email (or other services). There are applications that provide password-protected access to the application as a whole, and there are PGP clients and directory encryption utilities galore. Even with all of those add-ons activated, however, it will still be up to the user to make the final choice: would you rather have your phone check your email in the background (and store your account password in plaintext), or have your phone keep your password safe (and force you to supply a password for access). There's just no way to have it both ways.
Brief items Security quotes of the week
In a move that seems Big Brother-ish, Apple has a patent in the works that could use voice and facial recognition technology to activate a "kill switch" on its popular iPhone, shutting it down when hackers "jailbreak" or unlock the phone to install unauthorized programs on it, or try to steal information from an unsuspecting iPhone user.Apparently the FBI doesn't quite recognize that "Big Brother" is the government.
Although these tools need to be created by competent people, they are intended for mass use (point and click) and so copyright infringement by the masses will always be easy. They will not even know that the hurdles were there, because the tools will jump over them.
-- Richard
Clayton reports on the ineffective blocking in a "Site Blocking" report
Fortuitously, the DCMS have provided an illustration of this in their publishing of the OFCOM report... [...] What the DCMS [Department for Culture Media and Sport] have done (following in the footsteps of many other incompetents) is to black out the text they consider to be sensitive. Removing this blacking out is simple but tedious ... you can get out a copy of Acrobat and change the text colour to white — or you can just cut and paste the black bits into Notepad and see the text.
ShareMeNot is a Firefox add-on designed to prevent third-party buttons
(such as the Facebook "Like" button or the Twitter "tweet" button) embedded
by sites across the Internet from tracking you until you actually click on
them. Unlike traditional solutions, ShareMeNot does this without completely
removing the buttons from the web experience.
-- ShareMeNot
WASP: The Linux-powered flying spy drone that cracks Wi-Fi & GSM networks (Geek.com)Geek.com takes a peek at the Wireless Aerial Surveillance Platform (WASP), which is a repurposed US Army unmanned aerial vehicle (UAV or drone) outfitted to intercept WiFi and GSM. It will be demonstrated at the upcoming Black Hat and DEFCON security conferences. "If you happen to see this yellow drone flying above your neighborhood youd be right to be concerned. WASP is equipped with the tools to crack Wi-Fi network passwords made possible by an on-board VIA EPIA Pico-ITX PC running BackTrack Linux equipped with 32GB of storage to record information. BackTrack offers a full suite of digital forensics and penetration testing tools making it a good fit for this setup. [...] WASP can also act as a GSM network antenna meaning it will be able to eavesdrop on calls/text messages made over that network by any phone deciding to connect through it."
New vulnerabilities clamav: denial of service
erlang: predictable seeds used for random number generation
foomatic: arbitrary code execution
foomatic: arbitrary code execution
kernel: multiple vulnerabilities
libsoup: directory traversal
libwebkit: arbitrary code execution
mapserver: SQL injection
selinux-policy: unspecified vulnerabilities
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||