1. Database Security John Ortiz

2. Lecture 23Database Security2 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

3. Lecture 23Database Security3 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

4. Lecture 23Database Security4 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

5. Lecture 23Database Security5 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’

6. Lecture 23Database Security6 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)

7. Lecture 23Database Security7 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

8. Lecture 23Database Security8 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 multi- level security systems. Data is divided into classifications such that a user only has access to data at his/her classification or lower

9. Lecture 23Database Security9 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

10. Lecture 23Database Security10 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

11. Lecture 23Database Security11 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

12. Lecture 23Database Security12 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

13. Lecture 23Database Security13 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

14. Lecture 23Database Security14 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!

15. Lecture 23Database Security15 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

16. Lecture 23Database Security16 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