You know you shouldn’t have done that.
Richard Manion
Who am I?
(Not just an existential question)
Who are we?
3027282923242526171822201921131415160809111205100607020304
Leave with this!
• You matter!!• Don’t trust the client.• Sanitize your inputs.• Leave the viewstate MAC on.• Use the machine.config for enforcement.• Build patterns.
Why should you care?
• 430 “Software Developers, Applications,” or “Computer Programmer” in Dubuque
• 50/50 J2EE vs Java
Why should you care?
~200 .Net Developers in Dubuque
Why should you care?
• How many “Security Professionals and Network Architects” does the OOH report?
Why should you care?
• 1,890 “Software Developers, Applications” in the DSM metro (OOH)
• 50/50 J2EE vs Java
Why should you care?
~900 .Net Developers in DSM
Why should you care?
• 630 Security Professionals and Network Architects
• 78% of Security professionals are in “Identity Management”
• ~3400 App SANS certified application testers vs ~32000 certified generalists (~10%)
• ~13 Application Security Specialists in Des Moines
Why should you care?
1:71
Why should you care?
1:71
Why should you care?
Why should you care?
Do you think your security department
knows what you are doing?
Why show errors?
• Do they improve the user experience?– They aren’t pretty– They aren’t useful– They aren’t “friendly”
• Do you need them in production?– Is that where you are logging errors?– Can you just change it when you need it?– Is this just a screw up?
So…let’s not screw it up
• Set the customErrors behavior in your machine.config
• Use allowOveride=False• Bonus: Uniformity in
error messages
• When debugging– Set allowOveride=True– Change one web/app
config– Change it back
Don’t trust the client
• Why are you using query strings in a dotNet app?
• Why are you storing data in the cookie?And also:• Why did you turn off MAC in viewstate?
ViewState
• MAC: How .Net knows if the ViewState changed
• The ViewState is not encrypted• Why are you storing data in ViewState?
– Easy way to go from page to page• Why are you changing the ViewState at the
Client
• Don’t disable MAC• Don’t store sensitive stuff in the ViewState
ViewState
• If you cleaned it up on the client, and it was dirty when you got it, then….
• If you can’t limit it, escape it– If you escaped it on the client and it isn’t escaped
now, then…
How do you store passwords safely?
How do you store passwords safely?
YOU don’t!
How do you store passwords safely?
• On the Client rnd1 = SHA1(64charsofSalt + Password)
• A couple hundred times.. Rnd1=SHA1(Rnd1)• On the server RND2 =
SHA1(64charsofSomeAppSpecificSalt + Rnd1 + 64charsofSomeUser SpecificSalt)
• A couple hundred times rnd2=SHA1(rnd2)• Where AppSpecificSalt is stored in a different place
then User Salt (i.e. not in the DB).
How do you store passwords safely?
• Some security folks still won’t like this.• Requiring processing power is the enemy of
password cracking.• Never encrypt a password.• Don’t assume some other app is storing it
safely unless you asked.• You shouldn’t need to reuse that password--
think about your architecture.
My app isn’t important
• Your users reuse their passwords.• You are morally obligated to protect that
password like it is the password to the most secure thing it is being used for…because that is its value to the user.
• You don’t know what that is, but it is likely at least a bank account.
• Your user’s stupidity is your responsibility in this case.
Encrypting Data in .Net
• Hashing is not Encoding is not Encrypting• Use AES for Encryption with a 128-bit or
better key• You don’t need to know your IV, it shouldn’t
be IVIVIVIVIVIVIVIV• Encrypt(strA) != Encrypt(strA) if you did it
right.
Storing Encryption Keys
• “Different Places” File system, DPAPI, Registry, Database
• Store things in two places• Don’t put things in files that are in your
applications home folder (beside you aspx)• Why, oh, why would you put your encryption
key with your data?
Hard things to do:
• Writing encryption/hashing algorithms• Authentication• Authorization• PRNG- Random numbers