CSCE 548 CSCE 548 Secure Software Secure Software Development Development Weak Password-Based Systems Weak Password-Based Systems Store and Protect Data Securely Store and Protect Data Securely Information Leakage Information Leakage Failure to Handle Errors Failure to Handle Errors Correctly Correctly
58
Embed
CSCE 548 Secure Software Development Weak Password-Based Systems Store and Protect Data Securely Information Leakage Failure to Handle Errors Correctly.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
CSCE 548 CSCE 548 Secure Software DevelopmentSecure Software Development
Weak Password-Based Systems Weak Password-Based Systems Store and Protect Data SecurelyStore and Protect Data Securely
Information LeakageInformation LeakageFailure to Handle Errors CorrectlyFailure to Handle Errors Correctly
CSCE 548 - Farkas 2
ReadingReadingThis lecture:
– Howard et al., 19 deadly sins: Chapters 6, 13, 12, 11 (Howard et al., 24 deadly sins: Chapters 11, 12, 17, 19)
Identification Identification
Establishes the identity of an individual/system/ap-plication/etc.
Proof of identity: password, driver’s license, Id card, etc.
CSCE 522 - Farkas 3
CSCE 522 - Farkas 4
AuthenticationAuthentication Allows an entity (a user or a system) to prove its
identity within a context, e.g., computer system Typically, the entity whose identity is verified
reveals knowledge of some secret S to the verifier Strong authentication: the entity reveals
knowledge of S to the verifier without revealing S to the verifier
CSCE 522 - Farkas 5
Authentication InformationAuthentication Information
Must be securely maintained by the
system.
CSCE 522 - Farkas 6
Elements of AuthenticationElements of Authentication Person/group/code/system: to be authenticated Distinguishing characteristics: differentiates the
entities to be authenticated Proprietor/system owner/administrator:
responsible for the system Authentication mechanism: verify the
distinguishing characteristics Access control mechanism: grant privileges upon
successful authentication
CSCE 522 - Farkas 7
Authentication RequirementsAuthentication Requirements Network must ensure
– Data exchange is established with addressed peer entity not with an entity that masquerades or replays previous messages
Network must ensure data source is the one claimed
Authentication generally follows identification– Establish validity of claimed identity– Provide protection against fraudulent transactions
CSCE 522 - Farkas 8
User AuthenticationUser AuthenticationWhat the user knows
– Password, personal information
What the user possesses– Physical key, ticket, passport, token, smart card
What the user is (biometrics)– Fingerprints, voiceprint, signature dynamics
CSCE 522 - Farkas 9
PasswordsPasswords Commonly used method For each user, system stores (user name,
F(password)), where F is some transformation (e.g., one-way hash) in a password file– F(password) is easy to compute– From F(password), password is difficult to compute– Password is not stored in the system
When user enters the password, system computes F(password); match provides proof of identity
CSCE 522 - Farkas 10
Vulnerabilities of PasswordsVulnerabilities of Passwords Inherent vulnerabilities
– Easy to guess or snoop– No control on sharing
Practical vulnerabilities– Visible if unencrypted in distributed and network
environment– Susceptible for replay attacks if encrypted naively
Password advantage– Easy to modify compromised password.
CSCE 522 - Farkas 11
Attacks on PasswordAttacks on PasswordGuessing attack/dictionary attackSocial EngineeringSniffingTrojan loginVan Eck sniffing
CSCE 522 - Farkas 12
Password Management PolicyPassword Management PolicyEducate users to make better choicesDefine rules for good password selection
and ask users to follow themAsk or force users to change their password
periodicallyActively attempt to break user’s passwords
and force users to change broken onesScreen password choices
Digital CertificatesDigital Certificates
Most common digital certificate: X.509Initially issued in 1988Rely on PKI and hierarchy of certificate
authoritiesCertificate Authority: issue and revoke
digital certificates, accepts user notifications, publishes revocation list
CSCE 522 - Farkas 13
Digital Certificates Basic Digital Certificates Basic ContentContent
certificate for revocationWhy are digital certificates revoked?
– Exposure of private key– Incorrect/unauthorized issuance– Termination of assignment
CSCE 522 - Farkas 15
Return to Multiple Return to Multiple AuthenticationAuthentication
CSCE 522 - Farkas 16
I am Ann. Here is my X.509
System 1
System 3
System 2I am Ann. Here is my X.509
I am Ann. Here is my X.509
CA
Verify Certificate
Single Sign OnSingle Sign On
CSCE 522 - Farkas 17
I am Ann. Here is my X.509. Give me a locally verifiable token.
System 1
System 3
System 2I am Ann. Here is mySAML token
I am Ann. Here is my SAML token
SAML token
CA
Verify Certificate
CSCE 548 - Farkas 18
Information ProtectionInformation Protection During transit During use During storage
CSCE 548 - Farkas 19
Access ControlAccess Control
Protection objects: system resources for which protection is desirable– Memory, file, directory, hardware resource, software
resources, external devices, etc. Subjects: active entities requesting accesses to
resources– User, owner, program, etc.
Access mode: type of access– Read, write, execute
CSCE 548 - Farkas 20
Access Control Requirement Access Control Requirement Cannot be bypassedEnforce least-privilege and need-to-know
restrictionsEnforce organizational policy
CSCE 548 - Farkas 21
Access ControlAccess Control
Access control: ensures that all direct accesses to object are authorized
Protects against accidental and malicious threats by regulating the reading, writing and execution of data and programs
Need:– Proper user identification and authentication– Information specifying the access rights is protected
form modification
CSCE 548 - Farkas 22
Access ControlAccess Control
Access control components:– Access control policy: specifies the authorized accesses
of a system– Access control mechanism: implements and enforces
the policy Separation of components allows to:
– Define access requirements independently from implementation
– Compare different policies– Implement mechanisms that can enforce a wide range
of policies
CSCE 548 - Farkas 23
Authorization ManagementAuthorization Management
Who can grant and revoke access rights? Centralized administration: security officer Decentralized administration: locally autonomous systems Hierarchical decentralization: security officer >
departmental system administrator > Windows NT administrator
Ownership based: owner of data may grant access to other to his/her data (possibly with grant option)
Cooperative authorization: predefined groups of users or predefined number of users may access data
CSCE 548 - Farkas 24
Discretionary Access ControlDiscretionary Access ControlAccess control is based on
– User’s identity and – Access control rules
Most common administration: owner based– Users can protect what they own– Owner may grant access to others– Owner may define the type of access given to
others
CSCE 548 - Farkas 25
Access Matrix ModelAccess Matrix Model
Read
Write
Own
Read
Read
Write
Own
OBJECTS AND SUBJECTS
SUBJECTS
Joe
Sam
File 1 File 2
CSCE 548 - Farkas 26
ImplementationImplementationAccess Control List (column)
Functional DependencyFunctional Dependency FD: A B, that is for any two tuples in the
relation, if they have the same value for A, they must have the same value for B.
Example: FD: Rank Salary
Secret information: Name and Salary together– Query1: Name and Rank– Query2: Rank and Salary– Combine answers for query1 and 2 to reveal Name and
Salary together
CSCE 548 - Farkas 53
Key integrityKey integrityEvery tuple in the relation have a unique
keyUsers at different levels, see different
versions of the databaseUsers might attempt to update data that is
not visible for them
CSCE 548 - Farkas 54
ExampleExample
Name (key) Salary Address
Black P 38,000 P Columbia S
Red S 42,000 S Irmo S
Secret View
Name (key) Salary Address
Black P 38,000 P Null P
Public View
CSCE 548 - Farkas 55
UpdatesUpdates
Public User:
Name (key) Salary Address
Black P 38,000 P Null P
1. Update Black’s address to Orlando2. Add new tuple: (Red, 22,000, Manassas)IfRefuse update: covert channelAllow update: • Overwrite high data – may be incorrect• Create new tuple – which data it correct
(polyinstantiation) – violate key constraints
CSCE 548 - Farkas 56
UpdatesUpdates
Name (key) Salary Address
Black P 38,000 P Columbia S
Red S 42,000 S Irmo S
Secret user:
1. Update Black’s salary to 45,000IfRefuse update: denial of serviceAllow update: • Overwrite low data – covert channel• Create new tuple – which data it correct
(polyinstantiation) – violate key constraints
CSCE 548 - Farkas 57
Inference ProblemInference ProblemNo general technique is available to solve
the problemNeed assurance of protectionHard to incorporate outside knowledge