Windows and Smart Card Logon

Certificate logon

Motivation Kerberos smart card logon vs. TLS client certificate

authentication CA requirements Certificate requirements Enrollment agents

Motivation

Assumption

We are as secure as possible on Windows with standard Ethernet• no LM hashes• no plaintext passwords• no intrusion detection• Kerberos where possible• NTLMv2 if a must

Motivation

Passwords shorter than 12 chars are insecure Can be cracked from

• AD, local databases, password caches, NLTM and Kerberos traffic, LDAP simple bind, stored passwords, …

Windows passwords are MD4• cracking, Rainbow tables

Certificates are SHA-1 or SHA2• random keys, not transported easily without smart cards

SHA-1 problems

General brute-force attack at 2^80

6

Windows passwords

8 characters password? 80^8 possible passwords 2^x = 80^8 ??

• x * log 2 = 8 * log 80• x = 8 * log 80 / log 2• x ~= 51

10 characters ~= 2^63 12 characters ~= 2^76

7

Cracking 8 characters passwords

single CPU in Cain• 25 years

10 low-end GPUs in Distributed Password Recovery• days

Rainbow table• minutes• 576 GB

Kerberos

Rainbow tables inefficient due to salting• NTLMv2 as well

Can use smart cards Armoring on Windows 8/2012 Better services such as delegation, compound

authentication, claims Newer algorithms

• AES

Certificate logon

Kerberos vs. TLS

Kerberos TGT generation• password• PKINIT with certificate

TLS client certificate logon• require client certificate• prevents before-authentication attacks

CA requirements

Trusted NTAuth super-trusted CRL/OCSP available

CA best practices

Do not bother with hierarchy and offline roots May be on a DC

• the same threat and security level Always make CRL available on public DNS

• could be made internet accessible in the future

Certificate requirements

Domain Controllers• name of the domain• Smart Card Logon + Kerberos Authentication

User certificates• Kerberos PKINIT: Smart Card Logon• TLS client certificate auth: Client Authentication

Domain TLS User with RSAExtension ValueSubject Common Name or Distinguished Name

SAN UPN

Exportable Key no?

Archive Key no, transport encryption only

Key Type Signature

Key Usage Digital Signature

CSP all Base, Enhanced, AES providers

EKU Client Authentication1.3.6.1.5.5.7.3.2

Autoenrollment yes

Publish in AD no

Domain SC User with RSAExtension ValueSubject Common Name or Distinguished Name

SAN UPNor AD mapped subject (Windows 6.0+)

Exportable Key no?

Archive Key no, transport encryption only

Key Type Signature (AllowSignatureOnlyKeys GPO on Windows 6.0+)Encryption (required on 2000+, more secure)

Key Usage Digital Signature

CSP Smart Card compatible provider

EKU Smart Card Logon1.3.6.1.4.1.311.20.2.2can be empty on Windows 6.0+, but if present, must contain Smart Card Logon EKU

Autoenrollment no?

Publish in AD no

Enrollment Agent

aka Registration Authority (RA) Generates requests signed by its own RA certificate AD CS can apply more granular policies

Thank you!

GOPAS: info@gopas,cz | www.gopas.cz | www.facebook.com/P.S.GOPAS

[email protected] | www.sevecek.com |

Pripravované konferencie, semináre

11.11. 2013 To najdôležitejšie o TLS a SSL na Windows – Ondřej Ševeček

ShowIT 2014

11.-13.02.2014 Technická IT konferencia 60 prednášok Novinky z oblasti BackOffice, Development a Security Perlička: Ethical Hacking Prekvapenie: moderovaný speaker panel

Raňajky na tému:

Windows and Smart Card Logon

Documents

Transcript of Windows and Smart Card Logon