StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
18144689
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
6
CommunityOwnedDate
CreationDate
2013-08-09T10:30:22.953
FavoriteCount
0
LastActivityDate
2017-10-30T01:46:42.007
LastEditDate
2017-10-30T01:46:42.007
LastEditorUserId
1518423
OwnerUserId
1518423
ParentId
18144414
PostTypeId
2
Score
16
ViewCount
0
LastEditorDisplayName
text
Body
LocalStorage is under normal circumstances only accessible by your app. It is as secure as the sandbox on the specific platform (iOS, Android) is able to protect your app's data from being read by other apps. Sometimes that sandbox is not as strong as you might expect, e.g. in these cases: <ul> <li>the device is rooted or jailbroken</li> <li>the manufacturer failed to provide security updates or the user just didn't update</li> <li>the attacker has physical access to the device for example if it is stolen.</li> </ul> If the attacker has access to the cleartext password and username, she or he could try them also for other accounts (not just your service). So if the user of your app used the same password for multiple services, the attacker could gain access to them as well. What about storing a password hash? For server side applications this is a great idea, because they run in a protected environment (datacenters with access control, system engineers taking care of security updates). A phone, on the other hand, is stolen easily, and users often don't or can't install security updates. If the hash is not salted it is very easy to get the cleartext password using rainbow tables if you got the hash. If the hash is salted it is very easy to get the cleartext password for simple passwords. Also, it's very easy to generate insecure password hashes. Solution: store randomly generated access tokens: no matter how simple or complex the password is, it's just impossible to get the clear text password by looking at the token. TL;DR If you're using the credentials for authentication against some kind of API service, you should not store the password and username locally, even in a secure store such as the iOS keychain. What you should do instead is storing only a randomly generated token (NOT a password hash!) you get from that API (similar to the concept of storing the Session ID in a cookie rather than the user/pass combination). One possibility would be to use OAuth. That way you make sure the real credentials can never be leaked, even when the sandbox fails to protect the data or the phone is stolen.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHow secure is storing data with localStorage?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USstefreak
UserOwnerUserId
1. USstefreak
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.