×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Android Password Data Stored In Plain Text

timothy posted more than 2 years ago | from the so-don't-give-people-your-phone dept.

Android 261

jampola writes "The Hacker News is reporting that Android password data is being stored as plain text in its SQlite database. Hackers News says that 'The password for email accounts is stored into the SQLite DB which in turn stores it on the phone's file system in plain text. Encrypting or at least transforming the password would be desirable.' I'm sure most would agree encrypted password data in at least SHA or MD5 would be kind of a good idea!"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

261 comments

Sorry, disagree that SHA/MD5 is a solution (5, Insightful)

mysidia (191772) | more than 2 years ago | (#36864090)

I'm sure most would agree encrypted password data in at least SHA or MD5 would be kind of a good idea!"

No, I would not agree to that. I cannot say what most would think, but they would be misunderstanding the requirements and a misunderstanding of SHA/MD5 security for password stoarge, if they suggest SHA/MD5 as a solution.

When your android needs to access an e-mail account, knowledge of the actual login password is required, to connect to the remote server. Storing a SHA or MD5 hash does not retain knowledge of the password, so automatic e-mail login on the Android device would no longer be able to function with only a SHA or MD5 stored.

The e-mail server itself can potentially store a PBKDF2 derived strong hash for plaintext authentication over TLS (the server may require plaintext for CRAM-MD5 or other authentication mechanism selections), but your software needs to authenticate with the mail server, which requires either that actual credentials be stored, OR that credentials be entered by the user.

To quote the complaint from the article:

The password for email accounts is stored into the SQLite DB which in turn stores it on the phone's file system in plain text. Encrypting or at least transforming the password would be desirable.

I will agree that encrypting or transforming the password in the database is possible; something such as a Windows or OSX style keychain should be possible. HOWEVER, the decryption key has to be stored on the phone, and any transformation has to be reversible, for the device to still work without prompting the user for the password and saving in RAM or prompting the user every time e-mail is to be checked.

Therefore, the security benefits of doing this are absolutely minimal. Anyone who is actually trying to extract the password will learn about the transformation, and any reversible transformation is not a significant improvement.

Saving the unencrypted password in RAM may be just as good [or bad] as saving it on the filesystem, since phones are rarely rebooted, and RAM is subject to analysis just like a sqlite DB is subject to analysis.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

Anonymous Coward | more than 2 years ago | (#36864128)

Usually passwords on mobile devices use the PIN as the encryption key (+ some large salt). I'm wondering if Android does that but the people reporting this don't have a PIN set. In that scenario, I believe typically you still encrypt it with the salt to make things slightly more obscure (prevents against an attack where the exploit allows reading the sqlite db but not where the encryption key is stored).

Re:Sorry, disagree that SHA/MD5 is a solution (1)

mysidia (191772) | more than 2 years ago | (#36864270)

Usually passwords on mobile devices use the PIN as the encryption key (+ some large salt)

This is a possible approach; it has a potential drawback though. The phone cannot get e-mail in the background before the user types in their PIN, then. Also, PINs on a phone are likely to be simple, often numeric codes. If the user keeps their phone locked, they will want to have something they can key in very quickly to make a phone call in a hurry, which means that the PIN is likely to be brute forceable from a crypto point of view.

I believe typically you still encrypt it with the salt to make things slightly more obscure (prevents against an attack where the exploit allows reading the sqlite db but not where the encryption key is stored).

Obscurity is not security. And with the Android platform, the source code is available to a potential attacker. We can readily anticipate the hacker groups would quickly develop a tool, and publish details, so I wouldn't want to bank on an obscurity element here.

I agree encrypting the password and storing the key somewhere else may prevent an exploit that one case. Assuming (A) the attacker has the ability to read passwords from the SQLite database, but (B) the attacker does not have access to read passwords from other SQLite databases, and (C) your application doesn't store the encryption keys in the same SQLite database as the passwords.

Then it would follow the attacker can't decrypt the passwords.

The only question then would be.... how likely is it that the sqlite database containing the credentials can be compromised but the sqlite database containing decryption keys not be vulnerable?

Which is a difficult question to answer. Clearly though we would be looking at some sort of permissions or SQL injection vulnerability on the primary authentication database. Any vuln. where the attacker had control of the filesystem or RAM would be at greater risk of immediately exposing both databases.

The SQL injection on the credentials DB could be avoided by keeping the credentials database isolated from all other functions, and implementing strong filesystem level protections; such as authentication managed by a separate daemon through privilege separation, inside a different chroot jail, or user-mode filesystem invisible to other processes, with permissions limiting access to the DB file.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

pmontra (738736) | more than 2 years ago | (#36864278)

The PIN unlocks the SIM not the phone (I have experience only of European phones) and SIMs can be configured by users not to use PINs. My Android phone can even start up without a SIM and access the Internet over WiFi. So the PIN is not available to the phone all the time. Actually, I expect that the SIM does not disclose the PIN to the phone at all but I didn't check that.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

Joce640k (829181) | more than 2 years ago | (#36864564)

Oh yeah, people are known for having long PINs with a good mix of upper/lower case and symbols.

Not.

Salt? The whole point of salt is that it's known by the attacker. It's there to make sure that two identical files don't encrypt to the same cyphertext. It simply doesn't apply here.

There's not much you can do in this situation apart from asking the user to type in his email password 100 times a day. That would get old really quickly, I can't imagine many people would do it.

Re:Sorry, disagree that SHA/MD5 is a solution (0)

Anonymous Coward | more than 2 years ago | (#36864150)

...since phones are rarely rebooted...

I take it that you don't fly very often.

Re:Sorry, disagree that SHA/MD5 is a solutionj (1)

segin (883667) | more than 2 years ago | (#36864180)

My phone's "power off" is a suspend-to-RAM mechanism by default. HTC calls it "fast boot". Only by disabling "Fast boot" is power off really power off. Else yanking of the battery becomes a requirement.

Re:Sorry, disagree that SHA/MD5 is a solutionj (1)

pnewhook (788591) | more than 2 years ago | (#36864222)

Yup. Blackberry is the same way. Phone is never really 'off' unless the battery was pulled.

Re:Sorry, disagree that SHA/MD5 is a solutionj (1)

Flyerman (1728812) | more than 2 years ago | (#36864666)

yep, and you can't turn it off and then pull the battery. You have to pull the battery while the phone is on.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

Joce640k (829181) | more than 2 years ago | (#36864580)

I take it that you don't fly very often.

Maybe you should get a phone with an 'aircraft' mode...

Re:Sorry, disagree that SHA/MD5 is a solution (0)

Anonymous Coward | more than 2 years ago | (#36864152)

Mod parent up. I can't believe that Slashdot's editors are so technically clueless that they would post this story.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

Anonymous Coward | more than 2 years ago | (#36864174)

Full Ack. It seems like timothy is turning into the new kdawson, posting such an ignorant article.

Re:Sorry, disagree that SHA/MD5 is a solution (2)

maxume (22995) | more than 2 years ago | (#36864190)

If the app-server combo has a decent session protocol, the app can get a session token from the server and discard the password.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

joaosantos (1519241) | more than 2 years ago | (#36864232)

We are talking about standard email, so the protocol is plain IMAP or POP3.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

maxume (22995) | more than 2 years ago | (#36864522)

I agree that mysidia was mostly talking about email, but given the hilarious tendency of people to over-generalize information, it seemed worthwhile to point out that much of the problem is in supporting protocols that require frequent authentication.

Re:Sorry, disagree that SHA/MD5 is a solution (2)

mysidia (191772) | more than 2 years ago | (#36864342)

If the app-server combo has a decent session protocol, the app can get a session token from the server and discard the password.

I agree that's a very good idea. Why don't we implement Kerberos on our Android phones, and insist on GSSAPI with a Kerberos service ticket to access POP3/IMAP/etc from the phone?

Or certificate-based authentication, where we install a X509 certificate on our phone, and the server requires we authenticate with the right X509 certificate and use TLS/SSL in order to gain access to our account, instead of using a password.

Then each device is separate and lost device can be dealt with by revoking certs. Both of these are good solutions, but unfortunately, in most cases, neither will be an option, and people would not like the Android phones if it required them to introduce proper security to their mail server authentication, without addressing inconvenience issues.

Implementing token-based auth with IMAP or POP (unfortunately) requires special cooperation of the mail server admin, since most mail servers have no additional authentication options by default, beyond simple password; over SSL/TLS if you're fortunate.

The unpopularity of token-based auth for IMAP/POP stems from a lack of implementation of these security options on mail servers, partially due to the limited history of standardization of token-based auth, and the limited understanding most users have of the security issues with password storage and plaintext authentication.

Certificate based authentication has a problem that it's inconvenient, even though SSL/TLS is of course a very mature standard.

My impression is most sysadmins know nothing about token-based auth, GSSAPI, SASL, Kerberos, etc, would be words they never heard of, even if they actually manage Windows AD, they never heard of Kerberos.

So... as you can imagine... token-based extensions beyond the base standard for IMAP/POP mail access are not that well known or widely implemented.

Re:Sorry, disagree that SHA/MD5 is a solution (0)

Anonymous Coward | more than 2 years ago | (#36864418)

Another News Source is reporting that Android authentication data is being stored as plain text in its SQlite database. News Source says that 'The authentication information for email accounts is stored into the SQLite DB which in turn stores it on the phone's file system in plain text. Encrypting or at least transforming the authentication information would be desirable.' I'm sure most would agree encrypted authentication data in at least SHA or MD5 would be kind of a good idea!

Lets try it again. Some mechs do not transmit the password at all, only an MD5 hash of the password's MD5 hash and a challenge key. So, we truely could store _just!_ the MD5/SHA hash of the password, if the server reports it. Of course, if you get that hash, then you, too, can complete the challenge/auth, and we're back at the summary as posted above.

Something to be able to log in _MUST_ be stored on the machine. In your case, the session token would be stored, which an attacker could steal and log in with remotely... oh, it'll be locked to IP's? Well then you need to store the pass/derivative to relogin later when your IP changes again, back to point A.

Of course, all of this can be fully negated. Once the user verifies with a password, we can store that verification has been completed on the phone. When the user wants to check e-mail or whatever, we need only tell the server, "Yep, this user has been authenticated. Let me in."

Re:Sorry, disagree that SHA/MD5 is a solution (1)

gweihir (88907) | more than 2 years ago | (#36864248)

Was just about to post the same thing. The OP seems to have no clue how password security works.

Re:Sorry, disagree that SHA/MD5 is a solution (4, Insightful)

Macthorpe (960048) | more than 2 years ago | (#36864252)

Incredibly, if you actually RTFA, it's written by someone both technically incapable and clearly illiterate. It's also based on a comment made by a member of the Android team posted nearly a year ago, and the comment also points out exactly why they do it this way:

Simply obscuring your password (e.g. base64) or encrypting it with a key stored elsewhere will *not* make your password or your data more secure. An attacker will still be able to retrieve it. [...] If you can obtain *any* data from files in /data/data/* on a non-rooted device, this is a security problem in the device.

So basically, it's hidden from view on a non-rooted device, people who root their devices have already technically cracked their own security anyway, and even if it wasn't in plain text it would still be trivial to decrypt as the key has to exist somewhere on the device to do it.

All in all, very boring, very old, and very stupid to post.

Re:Sorry, disagree that SHA/MD5 is a solution (1, Insightful)

node 3 (115640) | more than 2 years ago | (#36864294)

Yeah, because it's Android, it's ok...

A few months ago: APPLE STORED YOUR LOCATION DATA IN PLAIN TEXT!!! HOW STUPID ARE THEY? THE ONLY EXPLANATION IS THEY ARE TRACKING YOU!!! PEOPLE WILL BE STALKED USING THIS!!!

Somehow, the OS X and iOS keychain manages to use encryption to protect passwords, the entire disk on iOS (after the 3GS, I think, maybe the 3G) is encrypted, and processes are blocked from reading files outside of their sandbox.

But on Android, it's +5 Insightful to say that plaintext password storage is hunky-dory. In fact, it's preferable! And as referenced by posts below, merely posting a story where someone says, quite meekly, that it might be "desirable", or a "good idea" to up the security on Android is grounds for mocking.

Re:Sorry, disagree that SHA/MD5 is a solution (0)

growse (928427) | more than 2 years ago | (#36864330)

And where does the iPhone store the encryption key protecting those passwords? On the device? Makes it a little bit useless then [msn.com] .

Go look at a blackberry to see disk encryption done properly - the key is not stored on the device, it's the derived from the user passphrase.

There's useless, and then there is USELESS (0)

SuperKendall (25149) | more than 2 years ago | (#36864366)

And where does the iPhone store the encryption key protecting those passwords? On the device? Makes it a little bit useless then.

As that article notes, you need physical access to the device. Not just being able to run software n the device, actual physical access to pull out the system keys.

You are trying to equate that to storing password in plaintext in a database that any app can just copy and send anywhere?

Re:There's useless, and then there is USELESS (2)

icebraining (1313345) | more than 2 years ago | (#36864410)

Where did it say that any app can copy it? They can't - it's stored in /data which is off limits to any app, unless you've rooted the phone.

Re:There's useless, and then there is USELESS (-1, Troll)

SuperKendall (25149) | more than 2 years ago | (#36864584)

They can't - it's stored in /data which is off limits to any app, unless you've rooted the phone.

Which as many Android enthusiasts point out is terribly easy to do. While it does not affect every user it affects huge subset of users.

On the iPhone, even if you've jailbroken it there's no such weakness thanks to the Keychain. Jailbreaking allows side loading, it does not break the entire security model and expose things as basic as email passwords.

Re:There's useless, and then there is USELESS (2, Informative)

Anonymous Coward | more than 2 years ago | (#36864718)

Rooting an Android phone doesn't break the security model either. It's not like apps suddenly run as root by default.

Re:There's useless, and then there is USELESS (1, Troll)

Barefoot Monkey (1657313) | more than 2 years ago | (#36864960)

They can't - it's stored in /data which is off limits to any app, unless you've rooted the phone.

Which as many Android enthusiasts point out is terribly easy to do. While it does not affect every user it affects huge subset of users.

On the iPhone, even if you've jailbroken it there's no such weakness thanks to the Keychain. Jailbreaking allows side loading, it does not break the entire security model and expose things as basic as email passwords.

No such weakness? What weakness are you talking about? GPP did not imply that rooting the phone causes /data to cease being off-limits to apps.

Re:There's useless, and then there is USELESS (0)

Anonymous Coward | more than 2 years ago | (#36864988)

Rooting doesn't break the security model either. Users granting root access to software from untrusted sources does.

Re:There's useless, and then there is USELESS (2)

growse (928427) | more than 2 years ago | (#36864720)

Apps can't read the database on non-rooted phones. So yes, you need physical access so you can root the phone first to get at the data.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

node 3 (115640) | more than 2 years ago | (#36864922)

And where does the iPhone store the encryption key protecting those passwords? On the device? Makes it a little bit useless then [msn.com] .

Um, the encryption key has to be on the phone at some point for it to work. Do you even understand encryption?

And the only way to keep it from being stored on the phone is to require some method for acquiring the key, either from the user, or from some external source (online, dongle, etc.).

You have severely misunderstood the article you linked to.

Go look at a blackberry to see disk encryption done properly - the key is not stored on the device, it's the derived from the user passphrase.

First off, I don't think you've described how it works on BlackBerry correctly. Second, the way it works on the iPhone is a key is generated, then it is encrypted with the user's passphrase. This is standard for encryption systems, including FDE.

Re:Sorry, disagree that SHA/MD5 is a solution (-1, Troll)

icebraining (1313345) | more than 2 years ago | (#36864386)

Oh look, another dumb person thinking that Slashdot is a single mind.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

node 3 (115640) | more than 2 years ago | (#36864796)

Oh look, another dumb person thinking that Slashdot is a single mind.

Where did you get such a foolish notion?

Re:Sorry, disagree that SHA/MD5 is a solution (0)

MobileTatsu-NJG (946591) | more than 2 years ago | (#36864870)

Oh look, another dumb person thinking that Slashdot is a single mind.

Yeah, imagine somebody making that mistake when moderation follows popular opinion. What a huge leap.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

Baloroth (2370816) | more than 2 years ago | (#36864486)

And, as a result, installing custom software requires jailbreaking the iDevice. I'm pretty sure thats the main reason (probably the only one, in fact) why Apple does this encryption. It also increases security, precisely because Apple can review every app that can be installed on the iDevice. The Android model is a bit less secure: but its far more open. Upping the security might be a good idea... but if it comes at the cost of this freedom and openness: then no. And yes, I realize not all Android phones are open and unlockable, and many companies do everything they can to lock it down. This, however, is not the fault of Android, but greedy phone makes and wireless providers.

Oh, and keychains don't add any real security, they just make it slightly harder to hack. Encryption is not magic. Encrypting with data on the device, as iPhones do, is nearly worthless.

Re:Sorry, disagree that SHA/MD5 is a solution (-1, Flamebait)

node 3 (115640) | more than 2 years ago | (#36864844)

And, as a result, installing custom software requires jailbreaking the iDevice. I'm pretty sure thats the main reason (probably the only one, in fact) why Apple does this encryption.

Seriously, you hear some of the dumbest fucking things about Apple here on Slashdot. Encrypting the FS makes iOS more secure for the end-user. Apple sells hardware to their end-users. So good things for their end user (like a secure filesystem) is the reason they do this.

The Android model is a bit less secure: but its far more open.

Bullshit. Android is *far* less secure. Where's all the iOS malware? You hear of many dozens of programs being pulled (often using Google's "kill switch", which never seems to ruffle any feathers here, but even the mere *existence* of Apple's "kill switch" (which they've never used) raised a ruckus. this is the exact same mentality that leads to the absurd idea in the first quote of yours above--that anything Apple does is for evil reasons, and anything Google does is for good reasons!).

Android is much less secure, by design, and it's more open, but not "far more open". Where's the source for Honeycomb?

And yes, I realize not all Android phones are open and unlockable, and many companies do everything they can to lock it down. This, however, is not the fault of Android, but greedy phone makes and wireless providers.

That's just apologetics. If Android is locked down and it's still Android, you can't just brush that off. Google specifically designed Android to allow for this, and they even bless these locked down phones as being proper Android, and not just some perverted branch of the AOSP, which is the only truly open version of Android, but is not Android proper.

Oh, and keychains don't add any real security, they just make it slightly harder to hack. Encryption is not magic. Encrypting with data on the device, as iPhones do, is nearly worthless.

Again, bullshit. Keychains add real security. You can't just mount the filesystem and read the contents of the keychain. You can't use an app on a rooted/jailbroken iPhone to read the keychain contents.

No one said "encryption is magic". But it's vastly better than plaintext storage.

It's pathetic that so many Slashdotters (who are supposed to be nerds) won't even accept that some sort of encrypted system is better than plaintext for storing password. Absolutely pathetic.

Re:Sorry, disagree that SHA/MD5 is a solution (0)

Anonymous Coward | more than 2 years ago | (#36864528)

Hint: possible Google stockholder(s).

Re:Sorry, disagree that SHA/MD5 is a solution (1)

Belial6 (794905) | more than 2 years ago | (#36864532)

That is a troll. The big problem with the iPhones wasn't that it was storing data in plain text. It was that Apple was collecting the data without the users knowledge. Apple then used doublespeak to make their fanboys believe that no data was being sent back to the mothership.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

jo_ham (604554) | more than 2 years ago | (#36864826)

And no data was. The database was local, and used to speed up location services on the phone.

In the ToS it says they may collect non-personal data for their own use, but no one has been able to demonstrate that they were actually doing that.

Regardless of what Apple were or were not doing, a major criticism from the Android fanboy camp was that this was all plaintext, making "tracking your every move" suspicious, and a massive privacy violation issue since anyone could get the data and work out where you were, or build up patterns of movement so they could see when you were most likely to be away from home to rob you etc.

Go look it up - it's all there.

Now, here we have Android phones storing *passwords* in plaintext, and somehow that's "perfectly ok, since the key must be on the device somewhere so it doesn't matter". Mmmm. Double Standard Cream. Delicious on a pie.

Re:Sorry, disagree that SHA/MD5 is a solution (2)

node 3 (115640) | more than 2 years ago | (#36864862)

That is a troll. The big problem with the iPhones wasn't that it was storing data in plain text. It was that Apple was collecting the data without the users knowledge. Apple then used doublespeak to make their fanboys believe that no data was being sent back to the mothership.

Absolute rubbish.

1. It was in the EULA. Not hidden or obscured, but out in the open.
2. The data found was a cache of Apple's location database. It never contained your actual location.
3. One of the issues *was* that it was in plaintext. Go to the slashdot article about it and control-f for "stalker" or "police".
4. Apple never claimed (or implied) that data wasn't being sent to them. In fact, they specifically stated that this is exactly what happens.

Re:Sorry, disagree that SHA/MD5 is a solution (0)

Anonymous Coward | more than 2 years ago | (#36864534)

You clearly don't understand the difference between "Not encrypting passwords the user has voluntarily entered" and "Secretly mining location data and not telling the user".

Here's a hint - it's nothing to do with double standards.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

node 3 (115640) | more than 2 years ago | (#36864872)

Hint: the location database cache was not "secretly mining location"
Hint: Apple did tell their users.
Hint: Lack of encryption was one of the complaints against Apple.

Re:Sorry, disagree that SHA/MD5 is a solution (0)

Anonymous Coward | more than 2 years ago | (#36864296)

That's a surprisingly insightful and informative first post.

Re:Sorry, disagree that SHA/MD5 is a solution (0)

Anonymous Coward | more than 2 years ago | (#36864322)

Right, you can only do this if the platform has some kind of local hardware-based security (e.g., sealed-up processing with armored key material).

It can be done; ARM defines bus-level security system, and there are ARM processors out there that the vendors would like you to believe are capable of this (e.g., the TI 3530 and later). But it would mean that the cell phone crowd would have to get a clue about real security, which is hard. Also the attack models start to look like "take cell phone, dunk in liquid nitrogen, extract contents of DRAM," though this is still a little science-fictiony.

I would /love/ to see a real secure execution platform on cell phones.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

Belial6 (794905) | more than 2 years ago | (#36864598)

OK, just brainstorming here, but how about a wireless fob that the phone can request the password from. The fob could be stored on your key chain, so if you lose your phone, the phone reverts back to the manual password and is as secure as passwords are, and if you lose the fob, you can just cancel it in the phone and re-sync to a new one.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

sjames (1099) | more than 2 years ago | (#36864678)

I would argue that a simple transformation is worse than storing in plain text because it provides security theater with no substance.

The real choices are simple:

  1. It can be left as-is with known risks.
  2. Make the user enter the password every time the mail app starts up
  3. Keep the password in a lockbox and make the user enter a master password every time the phone starts up (or needs the screen unlocked).

It might be nice to offer a choice, but I suspect most would end up choosing the current situation with only a few choosing to frequently enter a password.

Re:Sorry, disagree that SHA/MD5 is a solution (1)

guruevi (827432) | more than 2 years ago | (#36864926)

The problem is not that the password is stored on the device, that is a problem occurring regardless of the device. The problem is that the program stores the password in an open, unauthenticated data store that other programs can access and is not encrypted. You can create your own encrypted container and store passwords in it (like Firefox stores passwords internally) or rely on a system-wide per-program encrypted container (like Mac OS X Keychain). Android just uses an unencrypted SQLite database with hardly any access controls. Most Android devices are also not encrypted (as compared to most Blackberries and iOS devices) since the manufacturers leave that 'option' to the 'business-class' devices like the Motorola Droid Pro.

This is RICH (0, Flamebait)

Anonymous Coward | more than 2 years ago | (#36864114)

I remember all of the mocking Android users did of Apple's security faux pas. Tables have turned.

Re:This is RICH (2)

oobayly (1056050) | more than 2 years ago | (#36864230)

Yup, as an Android owner and developer I admit I've mocked other manufacturers for their school boy errors. Guess what my reaction was? Something along the lines of "oh for fucks sake, they had better fix this pronto".

That said, my fetchmailrc file on machines contain plain text passwords and rely on only the owner having read rights, so maybe I'm a hypocrite. Any encryption key will have to live on the device, so it'll be interesting to see opinions and suggestions.

Well submitter is clueless... (2)

Kjella (173770) | more than 2 years ago | (#36864126)

SHA and MD5 are hash algorithms, there's no way to recover the actual password from a hash. And since you need the password to log in, that doesn't make the slightest bit of sense. The best they could do is some symmetric encryption with the key hardcoded in the software as security through obscurity.

Re:Well submitter is clueless... (3, Insightful)

Mr Z (6791) | more than 2 years ago | (#36864156)

An alternative to security by obscurity would be to have an actual secured device-specific key on the device, and an encryption block that has sole access to that key. I've actually architected products in the past that have such things, and one of the use models was "user's bag of sensitive data", where you could put items in the bag (passwords, credit card #s, etc.) in a secure manner, and only pull them out as needed. You need to be careful with how you handle the information once it's outside the bag, but the main point is if someone takes the bag (the SQLite database, in this instance), it's valueless to an attacker.

The bag itself could be stored encrypted in whatever bulk storage is convenient, with a key that's only physically accessible to the encryption engine. The key is "device specific", meaning each chip gets a random key blasted into it in the factory. You couldn't take the secure bag image from one phone and plop it on another and read it.

Lest this sounds like science fiction, it isn't. The same technology is used and widely deployed for DRM and other such purposes. Heck, TPM does this same stuff. It could be used to protect your passwords, but there isn't as much money or emphasis on implementing that.

Trusted Platform Module (1)

tepples (727027) | more than 2 years ago | (#36864198)

with a key that's only physically accessible to the encryption engine.

The last time that was tried, where not even the owner of a device can access its keys, that was called the "Trusted Platform Module", and the Slashdot crowd was up in arms against it.

Re:Trusted Platform Module (1)

Mr Z (6791) | more than 2 years ago | (#36864340)

You may've missed the part where I said "Heck, TPM does this same stuff." TPM itself isn't evil. It can be put to good uses also.

Re:Well submitter is clueless... (1)

Tom (822) | more than 2 years ago | (#36864694)

That would make the sqlite file useless to an attacker, yes.

But if he can fetch the sqlite file, he has deep enough access to access other data on the device, very likely including the in-memory decrypted password.

You'd need more than just a safe storage. You would need an OS that does the proper segmentation as well. If you're doing that anyways, making sure nobody who shouldn't get access to the sqlite data in the first place is a lot easier.

For maximum security, of course, you'd want to do both.

Re:Well submitter is clueless... (1)

Mr Z (6791) | more than 2 years ago | (#36864798)

You'll note that I did say you'd need to be careful with the information when it's outside the bag. That's true whether the password gets stored on the phone, or the phone makes the user type the password every time it's used. If the password only gets stored in RAM, though, you can do things such as wipe buffers immediately after use, etc. to at least limit the size of the window involved. Finding the right bytes in the right VM page (after hacking your way to get access in the VM!!) isn't nearly as trivial as knowing what file to grab in the filesystem. And, if you're able to walk the VM at your leisure, I suspect you've got bigger problems to worry about.

Proper segmentation would prevent run-time attacks that allow you to view RAM that you're not supposed to see when the device is in a normal operating mode. What about devices like the police forensic scanners, that conceivably could use something like JTAG to dump all the flash, without any cooperation from the host OS? I guess at that point we're into a discussion as to what threat models matter most and which ones we're trying to solve, so we can fix the goalposts.

Re:Well submitter is clueless... (1)

Fireking300 (1852630) | more than 2 years ago | (#36864176)

You can use hash algorithms to protect passwords. If when a person creates a account. The server hashes it. Then when a person trys to log in it hashes the same password. If someone managed to hack the android servers for its passwords all they would be able to get is the hashes.

Re:Well submitter is clueless... (1)

F.Ultra (1673484) | more than 2 years ago | (#36864238)

This is not about some android-servers, this is about the android phone storing the password unencrypted locally on the phone. Which it must do since it otherwise cannot use it to authenticate with the e-mail provider.

Re:Well submitter is clueless... (0)

Anonymous Coward | more than 2 years ago | (#36864236)

SHA and MD5 are hash algorithms, there's no way to recover the actual password from a hash. And since you need the password to log in, that doesn't make the slightest bit of sense.

Well duh, you just brute-force the password out of the hash whenever you need it. Could take some time whenever you need to login somewhere, but should work just fine.

Beh (0)

Anonymous Coward | more than 2 years ago | (#36864132)

Is obvious that someone complaining about software storing passwords in plain text doesn't know how things work.

Re:Beh (1)

node 3 (115640) | more than 2 years ago | (#36864368)

Is obvious that someone complaining about <strike>software</strike> Android storing passwords in plain text doesn't know how things work.

FTFY

Everyone knows storing passwords in plain text is the worst possible way to store a password, and there exist ways (such as the OS X and iOS keychain) to store passwords that aren't so abysmally trivial to access.

But since this is Android, well, it's *stupid* to point something like this out! If it were iOS, though, the tone here would be very different. In fact, back when iOS stored the location database cache (*not* a list of where you were, but the cache of Apple's much larger location database, which can be used to infer larger areas in which you most likely were), this was seen on slashdot as a horrible thing!

You guys are practicing platform-centric hypocrisy, to such an extent as to completely rewrite reality to suit your preferences. There's a word that gets tossed around here for merely saying something *nice* about Apple, so I'm sure I don't have to actually write it. But do consider for a moment how many of you can ever use it again without contradiction.

Re:Beh (2)

Macthorpe (960048) | more than 2 years ago | (#36864606)

I don't think you actually understand anything about the issue. Do you know where the actual passwords on the device are stored? If you look into that, you'll see why further obfuscation is unnecessary. If a user can get access to the folder where these files are stored, they already have enough information to break any remaining encryption on the device.

It's sad that you see this as 'platform-centric hypocrisy' instead of what it is - a non-story dredged from a year old post by an Android engineer that only confirms what other rational people already know.

Re:Beh (1)

node 3 (115640) | more than 2 years ago | (#36864778)

Absolutely incorrect, and a perfect example of the Android fanboyism I was talking about.

There's absolutely no way to argue against the idea that plaintext password storage is the *worst* way to store passwords. Period. There is no further discussion.

Storing them in a place that is normally restricted is better than just storing them in the user's home directory, or in a globally accessible location. But to say there's no reason to encrypt the password is absurd. Somehow Apple does a great job with the keychain. There's no excuse for an OS to not have some mechanism for locking passwords away.

Further, the "hypocrisy" here is that when Apple stored a location database cache in plaintext, you lot were up in arms. Hypocrisy.

If a user can get access to the folder where these files are stored, they already have enough information to break any remaining encryption on the device.

That is absolutely incorrect. See the iOS/OS X keychain for more details.

Re:Beh (1)

Macthorpe (960048) | more than 2 years ago | (#36864850)

Further, the "hypocrisy" here is that when Apple stored a location database cache in plaintext, you lot were up in arms.

Yeah, don't think that was about it being in plaintext - it was about it being recorded at all, in secret, and then it being transferred to your PC, also in plaintext, and very easily available. The passwords in plaintext on the Android device are stored in a folder that cannot even be seen unless you root the phone, let alone access - and even then you're still subject to the usual sudo-style admin permissions to give apps access to it.

That is absolutely incorrect. See the iOS/OS X keychain for more details.

What, this iOS keychain? iOS keychain system crack can expose passwords [appletell.com]

Again - if you have that level of access, there's little you can't do. The iPhone must store the encryption key somewhere on the device or it's useless. It's only a matter of time until you or someone else finds it. It's not fanboyism to state the obvious.

Encrypt The Phone (4, Insightful)

steevven1 (1045978) | more than 2 years ago | (#36864136)

As a precaution, you can encrypt the entire phone's filesystem. The Droid Pro, for example, offers this feature as a part of the OS. Unfortunately, for this to be fully effective, this means choosing a STRONG (ie long and complex) password with which to unlock the phone each time you want to use it, which may be impractical.

Re:Encrypt The Phone (2)

growse (928427) | more than 2 years ago | (#36864272)

Blackberry's do exactly this. It works well, but a lot of people argue against the convenience. The thing about security controls is that they're rarely convenient, so it's always a trade-off.

Old News (5, Insightful)

Pirow (777891) | more than 2 years ago | (#36864138)

1. This is almost 1 year old "news".
2. Why does it matter? These passwords are generally transferred in plain text without any sort of encryption anyway (which is another issue, but these old protocols are well known to be insecure without SSL etc.) so if you have access to get to the file in question you have access to sniff out these passwords anyway which is just as simple.
3. Any one way hashing is no solution if you need to transfer the passwords in plain text anyway, what's your POP3 server going to do with a MD5 hash?

Re:Old News (0, Insightful)

Anonymous Coward | more than 2 years ago | (#36864220)

Why does it matter?? Had it been another very popular, alternate OS, you guys would be jumping all over it and screaming revolt. But hey, why does it matter right?

Re:Old News (1)

gilesjuk (604902) | more than 2 years ago | (#36864440)

Exactly. If Apple does it wrong it's the end of the world. Android does it then the fandroids come up with some technical excuse as to why doesn't matter to them.

SSL is supported on my mail accounts these days to stop accounts being harvested and used for spamming.

Re:Old News (1, Troll)

vinehair (1937606) | more than 2 years ago | (#36864506)

Sounds like you're a bit of a sore Apple user, or just an anti-Android person (why are people like this? I don't understand it) who is a bit threatened, or perhaps you just like to appear smarter than people by trying to point out that Slashdot is just as biased as any other place (which it is.) But trying to pretend that the competent technical folk on the site that have very correctly pointed out that this is a non-issue being propagated by people that don't actually understand what they're talking about, which is what I'm assuming you also are, as you didn't even continue to read the post you're replying to beyond the eleventh word.

Re:Old News (2)

MobileTatsu-NJG (946591) | more than 2 years ago | (#36864730)

Sounds like you're a bit of a sore Apple user...

To somebody that is more objective on the topic, he sounds like somebody who thinks noisy Slashdotters should at least be consistent. The whole 'competition is good' principle falls on its face if one company is held to a different standard than another's.

Re:Old News (2)

bonch (38532) | more than 2 years ago | (#36864784)

I think he made a very good point--that if this wasn't about Android, it would be treated as a big security issue. When it's Android, or more correctly, Linux, there are justifications and excuses made.

Calling him names isn't going to change the validity of the point he made.

Re:Old News (0)

Anonymous Coward | more than 2 years ago | (#36864672)

As to point 2: just because a majority of users still use non-SSL protocols to check their email doesn't mean I do. Don't assume that passwords don't need to be encrypted because they're going to be sent in plain-text over the wire anyway.

However, point 3 is absolutely valid.

Point 1 would be valid if it were fixed...

Re:Old News (3, Interesting)

bonch (38532) | more than 2 years ago | (#36864794)

Oh, well, hey, if a major security flaw is almost a year old, it's no longer news!

Why are Android security problems always justified and dismissed on Slashdot? If this was iOS, I suspect your post would be completely different.

MD5 is not encryption (2)

microbee (682094) | more than 2 years ago | (#36864170)

MD5 is a one-way hash, not encryption. You store the password in this form, you cannot go back to the original form.

You need the plain text password for interoperating with the email servers (or whatever services that need password). They may support a different transformation of the password instead of MD5. So there has to be a way to go get the original plain text password.

On the other hand, if you use SHA or other means of encryption, the phone still has to decrypt the password. There are two ways for the phone to get the key:
1. embedded on the phone, maybe generated randomly for each user. Still the key has to come from somewhere, so theoretically it's possible for any malware to find the key and use it.
2. ask for the key or passphrase from the user everytime the phone boots, like Firefox's password manager.

Re:MD5 is not encryption (1)

microbee (682094) | more than 2 years ago | (#36864210)

Correcting myself, SHA is a hash function too. I got it confused with the public key encryption.

Re:MD5 is not encryption (1)

Baloroth (2370816) | more than 2 years ago | (#36864436)

This. Maybe you could do some sort of hardware-level black-box encryption system (kinda like I how SIM cards already work). That way, simply reading the file system wouldn't be sufficient, you would need to actually be able to perform a hardware level request to decrypt the password. Doesn't add much security, but maybe better than nothing? Don't think it would be worth the cost, though. Anything able to read your filesystem if probably gonna be able to get around this.

What we really need are device tokens to authenticate the device to the your email server. I believe GMail has a system like this for people who activate two-factor authentication to allow email programs to work without being reauthenticated. This token would only work on that specific phone, so copying it wouldn't allow access to the email, though I'm not exactly sure how/if this would work. I'm sure there is someway. Obviously, combining the above two would work wonders (so the hardware black-box would do all the encryption, theoretically making it impossible to hack, and the encryption would be unique to this phone), but then you wouldn't be able to access your email except through that phone. Unless you use two-factor authentication, but since that usually involves calling your phone... might cause some problems.

Re:MD5 is not encryption (0)

Anonymous Coward | more than 2 years ago | (#36864442)

Any cryptographically secure hash function (i.e. not MD5...) can be used for symmetric encryption. You hash an initial value and a key, then you hash the result, then the result of that and so on. This generates a stream of numbers which depends on the key and the initial value and cannot be generated without knowing the two. XOR your data with that stream and you have encrypted your data. Decryption is symmetric.

As with all cryptography, the cipher algorithm is hardly the difficult aspect. You just choose from the proven ones. The crypto system surrounding the cipher is the thing that often goes wrong. In this case, where would you store an encryption key on the cell phone? That's what trusted platform modules are for...

Public key cryptography (1)

Omnifarious (11933) | more than 2 years ago | (#36864172)

It should generate a certificate for access to your account. The password should only be used the first time you log in to establish the certificate as one which has access to your account. You should then be able to go to the web and see what kind of history of access and operations each authorized certificate has been performing, and allow you to revoke any certificate which is misbehaving.

But that, of course, is good security that isn't a huge pain and a headache for the user. And, as we all know, and the TSA is fond of reminding us, security must be a tradeoff between ease of use and good security. So I'm guessing that solution will never be adopted.

Re:Public key cryptography (0)

Anonymous Coward | more than 2 years ago | (#36864224)

erm,

From the article, reply from android support:

"The first thing to clarify is that the Email app supports four protocols - POP3, IMAP, SMTP, and Exchange ActiveSync - and with very few, very limited exceptions, all of these are older protocols which require that the client present the password to the server on every connection. These protocols require us to retain the password for as long as you wish to use the account on the device. Newer protocols don't do this - this is why some of the articles have been contrasting with Gmail, for example. Newer protocols allow the client to use the password one time to generate a token, save the token, and discard the password."

Re:Public key cryptography (1)

growse (928427) | more than 2 years ago | (#36864298)

Given that a certificate is effectively just a very very long structured password, what stops me pinching the cert off the phone and using that to sign into the relevant service? A certificate doesn't solve the problem, it just changes the terminology slightly. It's still bits and bytes stored on the phone that can be used as a secret to access a service as a user.

If you want a device-specific password, Google already support that for their services through their two-factor authentication with application specific passwords [google.com] .

Re:Public key cryptography (1)

Omnifarious (11933) | more than 2 years ago | (#36864344)

Nothing. But there is no way data can be stored on the phone that cannot be used to access the service.

The best you can do is make sure that it's apparent when the phone is being used to do something via the service so a user can monitor it and cut off access is something untoward is happening.

Re:Public key cryptography (1)

growse (928427) | more than 2 years ago | (#36864384)

It's a good idea, and Google already do this. Scroll to the bottom of gmail and on the right there's a link that opens a windows giving a list of current open logged in sessions, as well as a history of sessions, giving datetime, IP address and type (Mobile, browser, IMAP, etc.).

Re:Public key cryptography (1)

Omnifarious (11933) | more than 2 years ago | (#36864376)

If you want a device-specific password, Google already support that for their services through their two-factor authentication with application specific passwords [google.com].

What I want is a password that is unguessable. Storing any kind of user password at all is totally unacceptable. I haven't used a password to remotely log into any of my computers for at least a couple of years now. Somebody who somehow got a copy of my password database would be unable to use it to get remote access to my computer. They'd have to get private keys instead.

I have separate private keys for each device capable of physically authenticating me. So if I lose any of those devices I can easily revoke its access to anything in a very short period of time without affecting my ability to use any of my other devices to.

Re:Public key cryptography (1)

growse (928427) | more than 2 years ago | (#36864454)

And that's brilliant, but what I'm saying is a private key is just a long password. They fall into the same password-factor space of 'something you know'. By thinking that a private key makes you any more secure than a password on the basis of anything other than password length is wishful thinking.

I believe you're also free to set your Gmail password to be 100 characters, making it effectively 'unguessable'.

Re:Public key cryptography (1)

DavidTC (10147) | more than 2 years ago | (#36864608)

Yes, and the second IMAP supports this standard you've invented, feel free to pester the Android people to implement it.

This article, however, is retarded. Of course the password is stored on the device. It couldn't access email if it wasn't.

As some people said, they could make it slightly better by encrypting the filesystem or the file, and requiring people to enter a password to decrypt it on startup. Although considering that telephone 'passwords' tend to be only 10000 different combinations, uh, those are trivially easy to crack with brute force.

But that's not anything close to what the article suggests, because the article was written by an idiot who thinks you can log into places with hashes of password instead of the actual password. (Which would, of course, defeat the entire point of using hashes in the first place.)

Re:Public key cryptography (1)

Tom (822) | more than 2 years ago | (#36864652)

The only thing certificates, hashes, challenge-response, etc. etc. gain you is the attacker doesn't learn your password itself. If you use the same password for other things, that's an advantage. But it doesn't prevent him from accessing your account after cracking your phone.

(and yes, /., it took less than a minute to type that. moronic system)

Cant get too worked up over this. (1)

Kenja (541830) | more than 2 years ago | (#36864194)

Given that by default you're auto-logged into your Google account, if someone has the phone they have email access. Would be nice if there was better security of course.

Password system's fault (1)

Superken7 (893292) | more than 2 years ago | (#36864206)

I would not blame this on Android's fault for the same reason many others have noted.

However, if this system is so insecure, why not use something else? I agree that standard mail-based servers have no choice, but maybe other services would be able to use other authentication systems such as token-based (OAuth style) or some sort of host verification procedures (using public-key cryptography, just like with SSH) instead of using the insecure password-based authentication mechanism.

Again, I understand that this is not possible for a service that only supports passwod-based authentication, but maybe Google could have provided a way of trusting them with your password (as in storing your passwords in their servers) and using a more secure authentication scheme on the smartphone--goog servers link.

Re:Password system's fault (1)

Tom (822) | more than 2 years ago | (#36864638)

The entire point of this kind of password storage is to remove user interaction.

Which at the end of days, no matter how you skin the cat, means that the phone must contain all the data it needs to authenticate itself to the server and access your e-mail account.
So no matter what solution you come up with, it will break at this point.

Yes, there are challenge-response or hashing ways that gain you one thing: Someone cracking your phone can access your mail, but he doesn't know the password itself, only its hash or response. That can be useful if you tend to re-use passwords (and honestly, who doesn't?).

A tiny step forward would be multi-password authentication. AKA I don't have one password that will unlock my account, but several (or as many as I want). That way I could give my desktop computer one, and my phone a different one. Now if my phone gets stolen or cracked, I don't have to change all my passwords, but only invalidate the ones that were on the phone. That would be a small convenience step, but no change in security (the effect of multiple passwords on brute-forcing, hacking, etc. is negliegable - so you're now a 5 in 25752 trillion instead of 1. Big deal)

Re:Password system's fault (1)

swalve (1980968) | more than 2 years ago | (#36864914)

No, the phone could be a Blackberry, and the passwords would not be on the phone.

Re:Password system's fault (1)

gl4ss (559668) | more than 2 years ago | (#36864968)

you guys are suggesting to make the phone a thin client terminal, in that case some credentials would be stored anyways there. anyhow, many, man phones from many, many vendors have sqlite db's full of juicy shit. anyways, the sqlite db itself should be user level protected on the android device itself, so if you or others don't root it, regular apps don't get to steal your passes --- this is the big deal really why this would matter. imagine if any application you let read files could read your email/g passes. that would suck. now any app can just read MOST of the stuff on the phone :).

Yawn (0)

Anonymous Coward | more than 2 years ago | (#36864326)

They only found this out now?

No SSL - that's the real problem (2)

Artem Tashkinov (764309) | more than 2 years ago | (#36864364)

Using public WiFi spots is a much more dangerous issue, since a lot of websites still don't employ SSL encryption of the traffic and your POP3/IMAP/HTTP credentials can be easily eavesdropped.

Like it's mentioned earlier not storing passwords in an open or reverse encryptable form is not possible, since your Android device has to supply plain text password to many Internet servers.

Bah (0)

Anonymous Coward | more than 2 years ago | (#36864484)

My password already looks like it's encrypted.

get a clue (3, Insightful)

Tom (822) | more than 2 years ago | (#36864574)

I'm sure most would agree encrypted password data in at least SHA or MD5 would be kind of a good idea!"

Yeah, because SHA1 and MD5 are one-way hashes which are just great if you actually, you know, need to know the password so you can tell the mailserver.

When I started reading /., one of the reasons was that the editors had enough of a clue to weed out submissions from people who had not the slightest idea what the fuck they were talking about. At that time, /. stood out from the mainstream publications, who generally didn't employ geeks and the normal journalist had to ask his geek friends about what this "HTML" thing he noticed at the end of every webpage address was.

Please. One thing we really don't need more of is people with half-a-clue meddling in security and giving advise. For us security professionals, the clueless secretary is not our worst enemy. She at least knows she knows nothing and will listen to us. Our worst enemy in the company environment is the self-proclaimed power user who think he knows what he's doing, but is in fact only messing things up. And because he thinks he's smart, he won't listen to the security department.

Now yes, there are better ways than storing the passwords in plain-text. Encrypting them would help. You'd think. But in order to decrypt them, you have to have the key. Which means you have to store it on the phone. Or in other words: Right next to the database.
So encrypting the sqlite data would be the equivalent of having a really good lock on your door, and hanging the keys on a nail right next to it. Anyone who breaks your phone enough to get the sqlite file will also be able to get the key file the same way. All you're doing is making everything more complicated and wasting CPU cycles on pointless crypto.

wtf (0)

Anonymous Coward | more than 2 years ago | (#36864674)

Did they take so many days to figure this out? I mean, Android was open source.

The issue with reversible encryption... (1)

Sits (117492) | more than 2 years ago | (#36864754)

The problem is "keyless" (no password or secret bits needed) encryption doesn't actually add any real security because the passwords have to be accessed without being "unlocked" first.

What do I mean? Imagine you protect the password database with a single password (e.g. the unlock code). Now swiping the password database wins me nothing because it still needs unlocking. Now imagine I have a desktop with password-less autologin - my choices are now complicated. I must either

  • Prompt the user the moment I need to access the password database
  • Store the users password in a form that it can be derived using information on the filesystem
  • Store the database unencrypted
  • The first one is unweildly for a phone (does an unlock code really provide enough bits to securely lock the database?). The second and the third are effectively the same. In fact the second case reminds me of the old password database from Netscape where if you swiped the password database and a key file you could find out the real passwords [mozilla.com] .

The Fix (0)

Anonymous Coward | more than 2 years ago | (#36864864)

Why not use a cookie sort of system like web browsers use? When I sign into yahoo email it will keep me signed in, but the browser isn't storing my password in browser history. The email protocols would need to be changed to support this though.

Less than worthless article (1)

MisterJohnny (2029510) | more than 2 years ago | (#36864894)

MD5 and SHA1? Are you serious? If they were in-fact stored as MD5 or SHA1, than those hashes would need to be sent to the mail server...in which case they are vulnerable to a pass-the-hash attack and would be just as effective as if they were in plain-text! In order for someone to get into your phone's SQLite database, it would involve stealing it and than running forensic tools until they found the database itself. And anyone here who assumes that there wouldn't be tools provided to decrypt any kind of potential Android e-mail encryption is fooling themselves.

from tfa (0)

Anonymous Coward | more than 2 years ago | (#36864920)

A Android user complain that , All passwords are stored in plane text on Disk via a message on discussion board of Android.

so you see, it's not storing in "plain" text but in "plane" text which is completely different
obviously

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...