StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
17528844
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-07-08T14:11:56.893
FavoriteCount
0
LastActivityDate
2013-07-08T14:11:56.893
LastEditDate
LastEditorUserId
0
OwnerUserId
156755
ParentId
16952245
PostTypeId
2
Score
2
ViewCount
0
LastEditorDisplayName
text
Body
Not a complete answer but an expansion of how salting works that was too long for a comment.. The salt shouldn't be treated as a string to be compared, it should be a part of the password that the end user doesn't have to type but is unique to that user. It's used to prevent a single compromised password breaching multiple accounts. Eg let's say we've got a really simple system on which Bob has the password <code>ABCDEF</code>. Passing <code>ABCDEF</code> through our hashing algorithm results in (say) <code>ED6522687</code> If an attacker gets access to the password list, they can only see the stored hash. Of course, if Jane also uses the same password, her hash is going to be <code>ED6522687</code> too - which means if you break into either account (through brute-force, social engineering, etc) you're going to get access to both accounts as you can see their hashes match. Salting is where something is done to the password before hashing that's unique to each user and repeatable. Salt should be predictable so let's say Bob and Jane's salts are random numbers. Now if you hash the password for bob <code>ABCDEF123</code>, you get a different hash to Jane's <code>ABCDEF456</code>. Note that this isn't a complete explanation. Some other things to consider: <ul> <li>There's no such thing as a random number in this context, only cryptographically secure random numbers - and how random they are is complex, related to entropy and other fun stuff.</li> <li>How quickly the hash is computed is a major factor with regards to hampering brute-forcing - hash algorithms like <code>bcrypt</code> are designed to be computationally expensive. unlike (say) <code>SHA2</code></li> <li>There's no reason for the user to submit (or even know) their salt.</li> </ul> Another observation which isn't usually emphasised enough... You should never trust anything you read on the internet about a topic like this - there are too many people who have incomplete understanding (I consider myself among them). So take this as reasons not to do it yourself, not a guide on how to do it.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POEncrypt/Decrypt a string based on a salt key
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USBasic
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.