Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Based on the feedback from the other answers to this question, additional research, and offline discussions, here is what we ended up doing...</p> <p>It was pointed out pretty quickly that the interaction model here is essentially exactly the same as the model used by Forms Authentication in ASP.NET when a "remember me" checkbox is checked. It's just not a web browser making the HTTP requests. Our "ticket" is equivilant to the cookie that Forms Authentication sets. Forms Authentication uses essentially an "encrypt some data with a secret key" approach by default.</p> <p>In our login web service, we use this code to create a ticket:</p> <pre><code>string[] userData = new string[4]; // fill the userData array with the information we need for subsequent requests userData[0] = ...; // data we need userData[1] = ...; // other data, etc // create a Forms Auth ticket with the username and the user data. FormsAuthenticationTicket formsTicket = new FormsAuthenticationTicket( 1, username, DateTime.Now, DateTime.Now.AddMinutes(DefaultTimeout), true, string.Join(UserDataDelimiter, userData) ); // encrypt the ticket string encryptedTicket = FormsAuthentication.Encrypt(formsTicket); </code></pre> <p>Then we have an operation behavior attribute for the WCF services that adds an IParameterInspector that checks for a valid ticket in the HTTP headers for the request. Developers put this operation behavior attribute on operations that require authentication. Here is how that code parses the ticket:</p> <pre><code>// get the Forms Auth ticket object back from the encrypted Ticket FormsAuthenticationTicket formsTicket = FormsAuthentication.Decrypt(encryptedTicket); // split the user data back apart string[] userData = formsTicket.UserData.Split(new string[] { UserDataDelimiter }, StringSplitOptions.None); // verify that the username in the ticket matches the username that was sent with the request if (formsTicket.Name == expectedUsername) { // ticket is valid ... } </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POGenerating cryptographically secure authentication tokens
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USErv Walter
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POGenerating cryptographically secure authentication tokens
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COhow are you finding this approach? I may be wrong, however, I think there is a bit of a flaw with it. The only thing required for the client request to be authorized is that the ticket can be decrypted on the server. If the ticket is intercepted during transit (e.g. packet sniffing) or even extracted from the mobile device it could be re-used by an attacker to send malicious requests. If you are using SSL then the first attack would be mitigated, however, the second is still viable.
      singulars
      1. PO
      1. USJames
    2. COWe are still quite happy with this approach. We do use SSL, so the sniffing issue isn't a concern. The ticket being extracted from a mobile device requires the mobile device be compromised and/or physically in the hands of an attacker. At that point, the attacker has already "won" and it's game over. No matter the technical details, this will always be the case if there is "remember my password" functionality. In our case, this is somewhat mitigated by the fact that a ticket is only good for 8 hours, so the attacker has a limited window of time to make use of the stolen ticket.
      singulars
      1. PO
      1. USErv Walter
    3. COthe reason I ask is because I actually thought it was a clever way of generating a token without actually having to write any security code yourself. However, I asked a [question](http://security.stackexchange.com/questions/19676/token-based-authentication-securing-the-token) on the IT Security site for some advice with regards to *how* secure it actually was and the opinion differs. It was more to do with the fact your using encryption to secure the token rather than a [MAC](http://en.wikipedia.org/wiki/Message_authentication_code).
      singulars
      1. PO
      1. USJames
 

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.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload