Enhancing Password Security: Proactive Checking, Salting, & Challenge-Response, Exams of Computer Science

Download Enhancing Password Security: Proactive Checking, Salting, & Challenge-Response and more Exams Computer Science in PDF only on Docsity! 1 May 20, 2004 ECS 235 Slide #1 Proactive Password Checking • Analyze proposed password for “goodness” – Always invoked – Can detect, reject bad passwords for an appropriate definition of “bad” – Discriminate on per-user, per-site basis – Needs to do pattern matching on words – Needs to execute subprograms and use results • Spell checker, for example – Easy to set up and integrate into password selection system May 20, 2004 ECS 235 Slide #2 Example: OPUS • Goal: check passwords against large dictionaries quickly – Run each word of dictionary through k different hash functions h1, …, hk producing values less than n – Set bits h1, …, hk in OPUS dictionary – To check new proposed word, generate bit vector and see if all corresponding bits set • If so, word is in one of the dictionaries to some degree of probability • If not, it is not in the dictionaries 2 May 20, 2004 ECS 235 Slide #3 Example: passwd+ • Provides little language to describe proactive checking – test length(“$p”) < 6 • If password under 6 characters, reject it – test infile(“/usr/dict/words”, “$p”) • If password in file /usr/dict/words, reject it – test !inprog(“spell”, “$p”, “$p”) • If password not in the output from program spell, given the password as input, reject it (because it’s a properly spelled word) May 20, 2004 ECS 235 Slide #4 Salting • Goal: slow dictionary attacks • Method: perturb hash function so that: – Parameter controls which hash function is used – Parameter differs for each password – So given n password hashes, and therefore n salts, need to hash guess n 5 May 20, 2004 ECS 235 Slide #9 Pass Algorithms • Challenge-response with the function f itself a secret – Example: • Challenge is a random string of characters such as “abcdefg”, “ageksido” • Response is some function of that string such as “bdf”, “gkip” – Can alter algorithm based on ancillary information • Network connection is as above, dial-up might require “aceg”, “aesd” – Usually used in conjunction with fixed, reusable password May 20, 2004 ECS 235 Slide #10 One-Time Passwords • Password that can be used exactly once – After use, it is immediately invalidated • Challenge-response mechanism – Challenge is number of authentications; response is password for that particular number • Problems – Synchronization of user, system – Generation of good random passwords – Password distribution problem 6 May 20, 2004 ECS 235 Slide #11 S/Key • One-time password scheme based on idea of Lamport • h one-way hash function (MD5 or SHA-1, for example) • User chooses initial seed k • System calculates: h(k) = k1, h(k1) = k2, …, h(kn–1) = kn • Passwords are reverse order: p1 = kn, p2 = kn–1, …, pn–1 = k2, pn = k1 May 20, 2004 ECS 235 Slide #12 S/Key Protocol user system{ name } user system{ i } user system{ pi } System stores maximum number of authentications n, number of next authentication i, last correctly supplied password pi–1. System computes h(pi) = h(kn–i+1) = kn–i = pi–1. If match with what is stored, system replaces pi–1 with pi and increments i. 7 May 20, 2004 ECS 235 Slide #13 Hardware Support • Token-based – Used to compute response to challenge • May encipher or hash challenge • May require PIN from user • Temporally-based – Every minute (or so) different number shown • Computer knows what number to expect when – User enters number and fixed password May 20, 2004 ECS 235 Slide #14 C-R and Dictionary Attacks • Same as for fixed passwords – Attacker knows challenge r and response f(r); if f encryption function, can try different keys • May only need to know form of response; attacker can tell if guess correct by looking to see if deciphered object is of right form • Example: Kerberos Version 4 used DES, but keys had 20 bits of randomness; Purdue attackers guessed keys quickly because deciphered tickets had a fixed set of bits in some locations 10 May 20, 2004 ECS 235 Slide #19 Multiple Methods • Example: “where you are” also requires entity to have LSS and GPS, so also “what you have” • Can assign different methods to different tasks – As users perform more and more sensitive tasks, must authenticate in more and more ways (presumably, more stringently) File describes authentication required • Also includes controls on access (time of day, etc.), resources, and requests to change passwords – Pluggable Authentication Modules May 20, 2004 ECS 235 Slide #20 PAM • Idea: when program needs to authenticate, it checks central repository for methods to use • Library call: pam_authenticate – Accesses file with name of program in /etc/pam_d • Modules do authentication checking – sufficient: succeed if module succeeds – required: fail if module fails, but all required modules executed before reporting failure – requisite: like required, but don’t check all modules – optional: invoke only if all previous modules fail 11 May 20, 2004 ECS 235 Slide #21 Example PAM File auth sufficient /usr/lib/pam_ftp.so auth required /usr/lib/pam_unix_auth.so use_first_pass auth required /usr/lib/pam_listfile.so onerr=succeed \ item=user sense=deny file=/etc/ftpusers For ftp: 1. If user “anonymous”, return okay; if not, set PAM_AUTHTOK to password, PAM_RUSER to name, and fail 2. Now check that password in PAM_AUTHTOK belongs to that of user in PAM_RUSER; if not, fail 3. Now see if user in PAM_RUSER named in /etc/ftpusers; if so, fail; if error or not found, succeed May 20, 2004 ECS 235 Slide #22 Key Points • Authentication is not cryptography – You have to consider system components • Passwords are here to stay – They provide a basis for most forms of authentication • Protocols are important – They can make masquerading harder • Authentication methods can be combined – Example: PAM 12 May 20, 2004 ECS 235 Slide #23 Overview • Access control lists • Capability lists • Locks and keys • Rings-based access control • Propagates access control lists May 20, 2004 ECS 235 Slide #24 Access Control Lists • Columns of access control matrix file1 file2 file3 Andy rx r rwo Betty rwxo r Charlie rx rwo w ACLs: • file1: { (Andy, rx) (Betty, rwxo) (Charlie, rx) } • file2: { (Andy, r) (Betty, r) (Charlie, rwo) } • file3: { (Andy, rwo) (Betty, r) (Charlie, rwo) } 15 May 20, 2004 ECS 235 Slide #29 ACL Modification • Who can do this? – Creator is given own right that allows this – System R provides a grant modifier (like a copy flag) allowing a right to be transferred, so ownership not needed • Transferring right to another modifies ACL May 20, 2004 ECS 235 Slide #30 Privileged Users • Do ACLs apply to privileged users (root)? – Solaris: abbreviated lists do not, but full-blown ACL entries do – Other vendors: varies 16 May 20, 2004 ECS 235 Slide #31 Groups and Wildcards • Classic form: no; in practice, usually – AIX: base perms gave group sys read only permit -w- u:heidi, g=sys line adds write permission for heidi when in that group – UNICOS: • holly : gleep : r – user holly in group gleep can read file • holly : * : r – user holly in any group can read file • * : gleep : r – any user in group gleep can read file May 20, 2004 ECS 235 Slide #32 Conflicts • Deny access if any entry would deny access – AIX: if any entry denies access, regardless or rights given so far, access is denied • Apply first entry matching subject – Cisco routers: run packet through access control rules (ACL entries) in order; on a match, stop, and forward the packet; if no matches, deny • Note default is deny so honors principle of fail-safe defaults 17 May 20, 2004 ECS 235 Slide #33 Handling Default Permissions • Apply ACL entry, and if none use defaults – Cisco router: apply matching access control rule, if any; otherwise, use default rule (deny) • Augment defaults with those in the appropriate ACL entry – AIX: extended permissions augment base permissions May 20, 2004 ECS 235 Slide #34 Revocation Question • How do you remove subject’s rights to a file? – Owner deletes subject’s entries from ACL, or rights from subject’s entry in ACL • What if ownership not involved? – Depends on system – System R: restore protection state to what it was before right was given • May mean deleting descendent rights too … 20 May 20, 2004 ECS 235 Slide #39 Implementation • Tagged architecture – Bits protect individual words • B5700: tag was 3 bits and indicated how word was to be treated (pointer, type, descriptor, etc.) • Paging/segmentation protections – Like tags, but put capabilities in a read-only segment or page • CAP system did this – Programs must refer to them by pointers • Otherwise, program could use a copy of the capability—which it could modify May 20, 2004 ECS 235 Slide #40 Implementation (con’t) • Cryptography – Associate with each capability a cryptographic checksum enciphered using a key known to OS – When process presents capability, OS validates checksum – Example: Amoeba, a distributed capability-based system • Capability is (name, creating_server, rights, check_field) and is given to owner of object • check_field is 48-bit random number; also stored in table corresponding to creating_server • To validate, system compares check_field of capability with that stored in creating_server table • Vulnerable if capability disclosed to another process 21 May 20, 2004 ECS 235 Slide #41 Copying • Copying: systems usually use copy flag • Other approaches possible – Example: Amoeba again; suppose Karl wants to let Matt read file Karl owns, but not propagate this right • Karl gives capability to server, requests restricted capability • Server creates new capability (read only here), and sets check_field of new capability to h(rights ⊕ check_field) • Server gives this to Karl, who gives it to Matt • Matt presents it to server to read file • Server looks in table to get original check_field, recomputes new check_field from original one and rights in capability – If this matches the one in the capability, honor it – If not, don’t