WRITTEN ON July 3rd, 2006 BY William Heath AND STORED IN Uncategorized

Chris Drake has started a list – see below. It seems more technical and generic-Internet based than applicable to government ID issues. So maybe we should comment to that effect. Any comments (or if you’re aware of an existing list) here I’ll assemble and email to christopher[at]pobox.comChris Drake’s Authentication threat list v1.0

########################################
### Authentication Threat List 1.0 ###
########################################

1. Confidence Tricks

1.1. phishing emails
1.1.1. to lure victims to spoof sites
1.1.2. to lure victims into installing malicious code
1.1.3. to lure victims towards O/S vulnerabilities to inject
malicious code
1.1.4. to lure victims into revealing information directly via
reply or via embedded FORMS within the email

1.2. telephone phishing
1.2.1. to directly extract auth info
1.2.2. to direct victim to spoof site

1.3. person-to-person phishing / situation engineering
1.3.1. to directly extract auth info (ask)
1.3.2. to direct victim to spoof site
1.3.3. shoulder surfing (aka 4.5.2)
1.3.4. physical attack – see 4.7

1.4. typographic attacks
1.4.1. spoofing (eg: paypa1.com – using a number 1 for a little L)
1.4.2. direct download of malicious code
1.4.3. browser exploit injection

1.5. online phishing
1.5.1. pop-up/pop-behind windows to spoof sites
1.5.2. floating

or similar elements (eg: emulating an entire
browser UI)

2. Remote Technical Tricks

2.1. spoof techniques
2.1.1. vanilla fake look-alike spoof web sites
2.1.2. CGI proxied look-alike web site (server CGI talks to real
site in real time – “man in the middle attack”)
2.1.3. popup windows hiding the address bar (3.4.1/3.4.2)
2.1.4.

simulated browsers (1.5.2)

2.2. iframe exploits (eg: 1.5.1/1.1.3) (spammers buy iframes to
launch 1.5 and 1.4 attacks)
2.3. p2p filesharing publication of products modified to
remove/limit protection – PGP, IE7, Mozilla, …
2.4. DNS poisoning (causes correct URL to go to spoof server)
2.5. traffic sniffing (eg: at ISP, telco, WiFi, LAN, phone tap…)
2.6. proxy poisoning (correct URL returns incorrect HTML)
2.7. browser exploits (correct URL returns incorrect HTML)
2.8. targeted proxy attack
2.8.1. directs to vanilla spoof web site (2.1.1)
2.8.2. uses CGI re-writing to proxy legitimate site (eg: convert
HTTPS into HTTP to activate traffic sniffing) (2.1.2)
2.8.3 activates 5.7
2.9. Authorized exploitation – see 3.5.

3. Local Technical Tricks

3.2. Software vulnerabilities (aka exploits – eg – 1.1.3)
3.1.1. Known
3.1.2. Unknown

3.2. Browser “toolbars” (grant unrestricted DOM access to SSL data)

3.3. Trojans
3.3.1. Standalone modified/hacked legitimate products (eg: PGP or
a MSIE7) with inbuilt protection removed/modified.
3.3.2. Bogus products (eg: the anti-spyware tools manufactured by
the Russian spam gangs)
3.3.3. Legitimate products with deliberate secret functionality
(eg: warez keygens, sony/CD-Rom music piracy-block addins)
3.3.4. Backdoors (activate remote control and 3.4.1/3.4.2)

3.4. Viruses
3.4.1. General – keyloggers, mouse/screen snapshotters
3.4.2. Targeted – specifically designed for certain victim sites
(eg paypal/net banking) or certain victim actions (eg:
password entry, detecting typed credit card numbers)

3.5. Authorized exploitation (authority (eg: Microsoft WPA/GA,
Police, ISP, MSS, FBI, CIA, MI5, Feds…) engineer a Trojan or
Viral exploit to be shipped down the wire to local PC,
potentially being legitimately signed/authenticated software.)

3.6. Visual tricks
3.6.1. browser address bar spoofing
3.6.2. address bar hiding

3.7. Hardware attacks
3.7.1. keylogger devices
3.7.2. TEMPEST
3.7.3. malicious hardware modification (token mods, token
substitution, auth device substitution/emulation/etc)

3.8. Carnivore, DCS1000, Altivore, NetMap, Echelon, Magic Lantern,
RIPA, SORM…

4. Victim Mistakes

4.1. writing down passwords
4.2. telling people passwords
4.2.1. deliberately (eg: friends/family)
4.2.2. under duress (see 4.7)
4.3. picking weak passwords
4.4. using same passwords in more than one place
4.5. inattentiveness when entering passwords
4.5.1. not checking “https” and padlock and URL
4.5.2. not preventing shoulder surfing
4.6. permitting accounts to be “borrowed”
4.7. physical attack (getting mugged)
4.7.1. to steal auth info
4.7.2. to acquire active session
4.7.3. to force victim to take action (eg: xfer money)
4.8. allowing weak lost-password “questions”/procedures

5. Implementation Oversights

5.1. back button
5.2. lost password procedures
5.3. confidence tricks against site (as opposed to user)
5.4. insecure cookies (non-SSL session usage)
5.5. identity theft? site trusts user’s lies about identity
5.6. trusting form data
5.7. accepting auth info over NON-SSL (eg: forgetting to check
$ENV{HTTPS} is ‘on’ when performing CGI password checks)
5.8. allowing weak lost-password “questions”/procedures
5.9. replay
5.10. robot exclusion (eg: block mass password guessing)
5.11. geographical exclusion (eg: block logins from Korea)
6.12. user re-identification – eg – “We’ve never seen you using
Mozilla before”
6.13. site-to-user authentication
6.14. allowing users to “remember” auth info in browser (permits
local attacks by unauthorised users)
6.15. blocking users from being allowed to “remember” auth info in
browser (facilitates spoofing / keyloggers)
6.16. using cookies (may permit local attacks by unauthorised
users)
6.17. not using cookies (blocks site from identifying malicious
activity or closing co-compromised accounts)

6. Denial of Service attacks

6.1. deliberate failed logins to lock victim out of account
6.2. deliberate failed logins to acquire out-of-channel subsequent
access (eg: password resets)

7. Please contribute to this document!

7.1. on-list – just reply
7.2. off-list – send to christopher@pobox.com

Contributors: Chris Drake
v.1.0 – July 2, 2006
#########################################
### /Authentication Threat List 1.0 ###
#########################################

One Response to “Authentication: what are we trying to protect against?”

 
Ideal Gov administrator wrote on July 3rd, 2006 9:53 pm :

Chris Drake writes –
Hi William,

Thanks for your reply and obvious concern. I “brain dumped” that list
of mine from an accumulated decade or two of knowledge and experience
in this field, and I was specifically thinking about how to protect
passwords entered in to HTML forms.

Since I happen to be continually annoyed by people overlooking stuff,
and declaring other stuff “out of scope” (usually for the convenience
of avoiding hard problems, although almost always accompanied by some
(A) less-than-honest or (B) uninformed-opinion-based differing
explanation) … I think it is a really good idea to include other
things in my “threats” – so that people don’t get the mistaken
impression that my list is a comprehensive solution to some kind of
problem they have in their mind – when they don’t realize that their
problem and my list are not necessarily the same thing…

My “context” is from the perspective of a computer system operator
attempting to protect my customers. While this may be a government
computer – I am thinking more along the lines of a personal identity
provider service (IdP): an independent “single sign on” system for the
internet (and beyond). This complicates the matter – since my IdP can
subsequently be *used* by other people, including government web
sites, for user authentication.

This poses quite a different set of security problems, but one
nonetheless that I’m quite aware of and able to solve.

SO… here’s what I *think* you mean – please correct me if I’m off
track:-

> threats from joined up/panoptical government

You mean “attacks” or “exploits” that may be mounted by persons with
privileged access to customer information ?

Most of the surveillance and other stuff that governments get up to
are already described in my technical threats sections – so a
government is no different to a hacker in that respect, and my threats
list a pretty good set of how they can attack.

An Obvious omission is physical attack against the server – I covered
physical client-side attacks – but I will add some stuff about
preventing the machine hardware from being seized, and preventing
seized information from being useful (eg: via one-way salted hashes).

> the threats to society posed by deliberate wrongdoers

This is an especially prickly problem, and one that I don’t have a
good solution to – and worse – one that the only “good solutions” I
can think of (biometrics – off the top of my head) are unacceptably
dangerous for the innocent. Another great point though, so I’ll add
“Enrollment problems” to my list. It’s such a classic obvious one,
I’m almost embarrassed I left that off.

I am not well versed in social engineering and political interference
problems, so any list you can formulate for me will be greatly
appreciated!

Kind Regards,
Chris Drake