Crash Recovery

Download Report

Transcript Crash Recovery

Database Security
John Ortiz
Secure Passwords
 Two main requirements for choosing a secure
password:
1) MUST be easy to remember
2) MUST be difficult to guess
 Do NOT pick any of these types of passwords
because they are easily guessed!
your name, spouse’s name, child’s name, pet’s
name, friend’s name, fantasy character’s
name, coworker’s name, ANYONE’S NAME
Lecture 23
Database Security
2
Secure Passwords (cont)
name of operating system or host computer
your license plate, SSAN, phone number
birth date, anniversary date, any significant
date
information easily obtainable about you
any word out of any dictionary
a single word (in any foreign language)
a place
slang or profanity
Lecture 23
Database Security
3
Secure Passwords (cont)
 Do NOT use any of these either!
Groupings of similar letters
patterns of letters on a keyboard such as
‘asdfgh’ or ‘qwerty’
any of the previous spelled backwards
any of the above followed or preceded by a
single digit
Lecture 23
Database Security
4
Secure Passwords
substituting similar numbers for letters:
0 for O, 3 for e, etc.
substituting similar characters for letters:
@ for a, ! for I
adding numbers to anything crackable
 tarot12, car9rot
using obscure words like ‘quamash’
Lecture 23
Database Security
5
Secure Passwords (cont)
 NEVER write down any secure password, since
it will then no longer be secure
 What is left?
Should be at least 8 characters, with one or
more special characters (such as !, @, #,
etc.), and one or more digits
first letter from each word in a line out of a
favorite book or song
Example: Off We Go in 2 the Wild Blue
Yonder (owg2wby)
Lecture 23
Database Security
6
Secure Passwords (cont)
groupings of unrelated words
Remember, a UNIX system only uses the
first 8 characters to develop the encrypted
password file!
 Do NOT use any examples from here
 Examples of CRACKED PASSWORDS
L0v3rs, br0nc0s, kaitlyn1
Qwerty1, hoquiam5, nitwit1
Lecture 23
Database Security
7
Security Mechanisms
 Discretionary Security – grant privileges to
users, including access to specific files,
records, attributes, etc.
May have r, w, x, d specified separately
 Mandatory Security – used to enforce multilevel security systems. Data is divided into
classifications such that a user only has access
to data at his/her classification or lower
Lecture 23
Database Security
8
Discretionary Mechanisms
 Authorization Identifier – refers to a user
account or group of accounts (login, password)
 Two levels of privileges:
Account level – privileges each account holds
independent of relations in DB
Relation level – control access to individual
relations or views
 SQL uses GRANT/REVOKE to assign privileges
Lecture 23
Database Security
9
GRANT Privileges
 SQL allows the granting of the following types
of privileges:
 SELECT (retrieval)
 MODIFY (update, delete, insert)
 REFRENCE (reference specific relations when
specifying integrity constraints)
 Views allow very specific control over which
attributes are visible to a particular user
 Privileges can propagate from one user to
another
Lecture 23
Database Security
10
REVOKE Privileges
 SQL allows the suspension of previously
granted privileges
 If a privilege has propagated, and the owner
account revokes it, all the propagated
privileges will also be revoked
Remember, this is not exactly how Oracle
implements this feature
 If an account receives privileges from 2 or
more sources, then the privileges are only
revoked if all sources revoke them
Lecture 23
Database Security
11
Mandatory Access Control
 Security Classes:
Top Secret – revelation may cause
catastrophic damage to U.S. security
Secret – revelation may cause grave damage
to U.S. security
Confidential – revelation may cause damage
to U.S. security
Unclassified – read it in the newspaper
Lecture 23
Database Security
12
Mandatory Access Control (cont)
 May read any data up to your level of
classification
 May write to any data at or above your
classification (can NOT write to lower
classification because it may contain higher
level information)
 In a relational database, attributes are given a
classification level
 In addition, the tuple itself is classified at the
highest level of any of its attributes
Lecture 23
Database Security
13
Mandatory Access Control (cont)
 An apparent key is the set of attributes that
would have formed the PK in a regular DB
 A multilevel relation will appear different to
different users – some parts of the PK may be
classified at a higher level
 In some cases, tuples stored at a higher level
can be downgraded and viewed at a lower level
 In other cases, 2 sets of tuples may need to be
stored
 Interesting possibilities for Norm., CC & R,
Consistency, etc. - EVERYTHING IS HARDER!
Lecture 23
Database Security
14
Multilevel Security
 Entity Integrity – all attributes that are
members of the apparent key must not be null
and must have same security classification
within each tuple
All other attributes must have classification
greater than or equal to apparent key
Lecture 23
Database Security
15
Statistical Database Security
 Protect access to individual data items, but not
the aggregate results
 Possible to infer individual data from some
statistical queries (I.e. if the query limits the
number of tuples to just a few)
 Solutions:
Restrict queries that only access a few tuples
Restrict repeated access to same data set
Lecture 23
Database Security
16