You know you shouldn’t have done that.

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


~200 .Net Developers in Dubuque


• How many “Security Professionals and Network Architects” does the OOH report?


• 1,890 “Software Developers, Applications” in the DSM metro (OOH)

• 50/50 J2EE vs Java


~900 .Net Developers in DSM


• 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


1:71


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?


YOU don’t!


• 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).


• 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

You know you shouldn’t have done that.

Documents

Transcript of You know you shouldn’t have done that.