ISOL536 | Security Architecture and Design Dr. Justin O. Hensley School of Computer and Information Sciences 1 Web, Cloud, and Account Threats Chapters 13 & 14 2 Agenda Web threats Cloud threats Account threats 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 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 (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 Note to instructor: there are random white boxes on the slide where I re-arranged figure 14-2 12 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 Unintentio ...

1. ISOL536 | Security Architecture and Design
Dr. Justin O. Hensley
School of Computer and Information Sciences
1
Web, Cloud, and Account
Threats
Chapters 13 & 14
2
Agenda
Web threats
Cloud threats
Account threats
Web Threats

2. 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

3. 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
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

4. 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

5. 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
Note to instructor: there are random white boxes on the slide
where I re-arranged figure 14-2
12
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

6. 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

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

8. 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

9. 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 malicious, don’t mark her as such
based on the previous (bad) source

10. Summary
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
Chapter 14 ■ Accounts and Identity 261
c14.indd 07:52:38:AM 01/15/2014 Page 261
Spoof Client
Obtain
credentials
Transit
Change
management
Storage

11. At server
At KDC
Authentication
UI
Insufficient
authentication
Local login Null creds
Guest/anon
creds
Predictable
creds
Factory default
creds
Downgrade
authentication
Privileged
access
Remote spoof
At 3rd party
At client
Federation
issues

12. Backup
authentication
Knowledge based
authentication
(KBA)
Chained
authentication
Information
disclosure
(e-mail)
No
authentication
Other
authentication
attack
Figure 14-2: Spoofing an external entity threat tree
Let’s fi rst consider spoofi ng threats at the server, whether you
describe the
threat as threats of the server being spoofed or of the server
spoofi ng; it’s six
of one, half a dozen of the other. The key is that the client is,
for whatever
reason, confused about the identity of the server it’s talking to.
As discussed
previously, the key to mitigating these threats is mutual
authentication, and in

13. particular cryptographic authentication. If you’re implementing
a new login
Chapter 14 ■ Accounts and Identity 261
c14.indd 07:52:38:AM 01/15/2014 Page 261
Spoof Client
Obtain
credentials
Transit
Change
management
Storage
At server
At KDC
Authentication
UI
Insufficient
authentication
Local login Null creds
Guest/anon
creds

14. Predictable
creds
Factory default
creds
Downgrade
authentication
Privileged
access
Remote spoof
At 3rd party
At client
Federation
issues
Backup
authentication
Knowledge based
authentication
(KBA)
Chained
authentication
Information
disclosure
(e-mail)

15. No
authentication
Other
authentication
attack
Figure 14-2: Spoofing an external entity threat tree
Let’s fi rst consider spoofi ng threats at the server, whether you
describe the
threat as threats of the server being spoofed or of the server
spoofi ng; it’s six
of one, half a dozen of the other. The key is that the client is,
for whatever
reason, confused about the identity of the server it’s talking to.
As discussed
previously, the key to mitigating these threats is mutual
authentication, and in
particular cryptographic authentication. If you’re implementing
a new login