Assignment-6

ISOL536 Security Architecture and Design

Week 6 Web Threats

Cloud Threats Account Threats

Agenda

• Web threats

• Cloud threats

• Account threats

• Reading: Chapter 13 & 14

Web Threats

• The web is software like other software

• There are specific attack classes like Cross Site Scripting (XSS)

– In much the same way that stack smashing is a “feature” of C or other weakly typed languages

– Threat modeling not needed to help find these

– Finding these in TM is a distraction from the unique threats to your software

Web Site Threats

• Attack surface/Trust boundaries

• Dependencies

• Not showing outbound links

– Is Google analytics safe? (We hope so—it’s on each page!)

• Model helps you consider each part & relationships

Threatmodelingbook. com

Web hosting

Browser

Google Analytics

Textbook web site

DB

Browser Threats

• Mostly the job of a small number of browser makers

• Your job when writing a plugin

– Manage security & privacy

• Literature reviews & careful checking of browser API guidance

Cloud Threats

• New insiders

– At the cloud provider — How do they compare to other IT outsourcing?

– Co-tennants as threats

• Compliance threats

– Regulation: what needs to be compliant?

– Audit & logging: what’s logged where and how?

– Can your controls migrate?

Cloud Threats (2)

• Legal

– In US, subpoena rules change if you give your data to others (“3rd party doctrine”)

• Forensic

– Can you get the hard drives, etc for analysis?

• Integrity

– Creation and management of virtual machines

Accounts Agenda

• Intro

• Account creation & maintenance

Accounts (overview)

• Accounts for systems

• Identity management manages accounts across many systems – Sometimes used as jargon to mean “account”

• Need to create, maintain and retire accounts – Close-relationship accounts vs free accounts

• Accounts that don’t map to a person – Joint bank accounts etc

• Need to authenticate account-holders – Even when they lose their authenticators

– The hardest problems are here

Account Create/Maintain/Delete

• Mostly “normal” engineering with relatively few traps

• Who can get an account?

• How do you ensure information stays up to date?

• What happens when the account-holder quits/leaves/passes away?

Authentication is Hard

• Traditional authentication factors – Something you know (including passwords)

– Something you are (biometrics)

– Something you have (Smartcard, ID card)

• Something you forgot, something you were, something you lost

• Multi-factor/Additional factors – Originally meant more than one from the list above

– Several things you know are not “multi-factor”

– Someone you know

– Elements like IP address, client fingerprinting

Managing Authentication is Hard Spoofing a Client

Login Failures

• “Incorrect username or password”

– Comes from a time that identifying accounts was thought to be hard

– Past its prime; usability win from telling people which was wrong outweighs risk

• Account lockout

Threats to Passwords

• Unintentional small disclosure

– Post-its, wikis, phishing

• Online attacks against the login system

• Offline attacks against a stolen database

– Good design can win you some time

– Modern password attacks are fast: O(1 billion/sec)

– Salting and iteration is better than not

– If your password is ‘123456’ the salting won’t help

– Practical iteration counts from 1000-1000000 barely help

Account Recovery is Hard

• “Forgot your password?” there’s many ways to get back into account – Most are substantially less secure than a half-decent

password – Most are always accessible to attackers

• Goal: account access, not password recovery! – Who cares about the old password? – Password recovery implies cleartext storage

• Many technical choices – Email, social authentication, knowledge based (secret

questions, public records, etc)

Email Alternate Authentication

• Email a new password or access token

– “Obviously” you can’t mail them old password

• Threats

– Information disclosure (eavesdroppping, attacker access to email)

– Denial of service (customer no longer has access to the email)

Knowledge Based Authentication (KBA)

• “What’s your password” is one end of the spectrum – Ideally, known only to you and customer

– Unfortunately, often shared or forgotten

• Leading to – Secret Questions

– Public records (aka “out of wallet”)

– Data only you should know (“Tell us how much we just deposited into your account.”)

Issues with KBA

• Security – “What color are your eyes” has few answers

– Names are differently popular (Mike vs Lawrence)

– Mothers maiden names on genealogy websites

– Et Cetera

• Usability – Applicability – not everyone has a first pet

– Memorability (was Ms Robinson 1st or 2nd grade?)

– Repeatability (Main Street vs Main St)

Social Authentication

• Passive: Identify these pictures of your friends

– Easy for you, hard for an attacker (we hope)

– Threats: friends with pictures of their pets, pictures with name badges

• Active

– Account trustees can help you get back in

– Takes longer

– You may no longer trust your trustees

Names

• Get tricky for computers

– Which Tom Jones?

– “mom”

• Real names don’t help you with security

– People are still jerks

– Policing risks offense

• Secure, human meaningful, decentralized: pick two

Meaningful ID

• Calls to mind the right person for the user

• Requires knowing the person

• The person that “mom” calls to mind is different for each us us, and that’s ok

• Must be presented in a way that’s hard to spoof

• ID documents are opposite of meaningful ID

Social Security Numbers

• Used as identifiers and authenticators

– This is an awful pattern

– An authenticator known to many parties and not subject to change is a bad pattern

• Bad as a database key

• Not everyone has one

• These problems generalize to other identification schemes

Identity Theft

• Often just another name for fraud by an impersonator

• Sometimes much worse – Database records intermingled and confused

– “The computer is always right”

– Reputational damage

• Be careful linking data from various sources

• Be careful when you correct data not to allow another source to override it – If Alice proves she’s not a deadbeat, don’t mark her as

one based on the previous (bad) source

Recap

• To threat model web sites, focus on dependencies and unique functionality

• Cloud: focus on trust boundaries

• Accounts:

– “Backup” auth is just another way into an account

– Social authentication is probably strongest when it meets business goals

– Names, SSNs are harder than you think

What’s next?

• Quiz 4

– Due Sunday 11:59 PM

– 20 multiple choice questions

– 20 minutes

– You have 2 chances (take highest grade)

• Reach chapter 15