Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Too bad you can't use the LDAP to signon to TSO.. I understand what your saying Timothy. The big trick as we have found is design.. Plan seems to be a bad 4 letter word Scott ford www.identityforge.com On Jul 24, 2012, at 8:06 PM, Timothy Sipples timothy.sipp...@us.ibm.com wrote: Shmuel Metz writes: No, you answered a different question. Can you log on to a TSO foreground session using a long userid that is not defined in TDS but only in a 3rd party LDAP server. TSO/E unaided supports up to 7 character IDs. (Let's not call them user IDs for now. They could be individual humans or not.) However, you can build and deploy whatever challenge(s) you want in front and/or behind that. You can use the LDAP client provided with base z/OS as the fundamental building block for that/those challenge(s). LDAP is LDAP -- assuming your third party LDAP server is standards compliant. The TSO/E ID could even be stored and retrieved from that LDAP server and automatically provided to TSO/E if you wish. I'm not necessarily recommending (nor not not recommending) you do that. (Conveniently IBM also provides a wonderful LDAP server in base z/OS.) But I think you can do what you want with the ingredients in base z/OS and a little effort above that. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Shmuel Metz asks: There is support for mapping long user ids into short user ids. Does that support work if the access validation is in a third party LDAP server? Base z/OS includes LDAP client support, provided in the Tivoli Directory Server for z/OS. I already answered yes, so I'll vote yes again. :-) 2. Note that you are not required to use TSO/E user IDs as user IDs. You are if you want to log on to TSO foreground, which is what I asked about. You perhaps missed my point there. You can consider TSO/E user IDs to be tokens in a pool if you wish, and they may or may not be unique per individual. That's a policy and implementation question which your organization gets to decide. But I explicitly asked about TSO. The original poster didn't make that clear. I did. Scott Ford adds: Sales pitch, sorry guys...I will bet there are thousands and thousands of users using either TSO or CMS ..of course CICS and IMS and DB2 ...we also sell software ...LDAP ...but I won't go there unless its offline. This isn't the place to try to hustle ppl If that comment was aimed at me, it was not well aimed. The only thing I've been doing is suggesting solutions, most or all of which happen to require nothing but what you have in z/OS. Let me repeat: *everybody* who licenses *base* z/OS gets IBM's LDAP server and client. OK, so if this -- enhanced (or at least different) authentication and/or authorization for TSO/E applications -- isn't a real problem for you, fine, you can ignore this thread. Alternatively, if you don't like my proposed solutions, send IBM a formal enhancement request through the proper channels along with your suggested solution design. Feel free to borrow my suggestions if you like them. No royalties are required. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Sorry we are competitors I won't say more Scott ford www.identityforge.com On Jul 22, 2012, at 8:38 PM, Timothy Sipples timothy.sipp...@us.ibm.com wrote: Shmuel Metz asks: There is support for mapping long user ids into short user ids. Does that support work if the access validation is in a third party LDAP server? Base z/OS includes LDAP client support, provided in the Tivoli Directory Server for z/OS. I already answered yes, so I'll vote yes again. :-) 2. Note that you are not required to use TSO/E user IDs as user IDs. You are if you want to log on to TSO foreground, which is what I asked about. You perhaps missed my point there. You can consider TSO/E user IDs to be tokens in a pool if you wish, and they may or may not be unique per individual. That's a policy and implementation question which your organization gets to decide. But I explicitly asked about TSO. The original poster didn't make that clear. I did. Scott Ford adds: Sales pitch, sorry guys...I will bet there are thousands and thousands of users using either TSO or CMS ..of course CICS and IMS and DB2 ...we also sell software ...LDAP ...but I won't go there unless its offline. This isn't the place to try to hustle ppl If that comment was aimed at me, it was not well aimed. The only thing I've been doing is suggesting solutions, most or all of which happen to require nothing but what you have in z/OS. Let me repeat: *everybody* who licenses *base* z/OS gets IBM's LDAP server and client. OK, so if this -- enhanced (or at least different) authentication and/or authorization for TSO/E applications -- isn't a real problem for you, fine, you can ignore this thread. Alternatively, if you don't like my proposed solutions, send IBM a formal enhancement request through the proper channels along with your suggested solution design. Feel free to borrow my suggestions if you like them. No royalties are required. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Passwords and user-ids was Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On Fri, 20 Jul 2012 23:22:38 -0300, Clark Morris wrote: If you believe that user-ids should be larger than 7 characters or even 8, then what are the implications for SMF records and various control blocks in z/OS? Many modern products use XML to avoid such hard limits. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Shmuel Metz asks: Can you log on to TSO foreground with an 8-character userid using the LDAP client, or do you need TDS for that? I'm not sure I understand the question, but I'll attempt an answer. 1. Unaided, TSO/E supports up to 7 character user IDs. 2. Note that you are not required to use TSO/E user IDs as user IDs. That is, one ID might not necessarily be associated with one and only one human. 3. TSO/E is a part of z/OS, but most people who use z/OS these days probably aren't using TSO/E. 4. TSO/E still runs lots of important applications that must not break, and that's evidently the primary reason why #1 hasn't changed. However... 5. You can place practically anything you wish in front of TSO/E in a variety of ways to provide additional security challenges before granting access to TSO/E. In other words, you can control access to all TSO/E on ramps. (One possible way is to use Certificate Express Logon.) 6. You can have additional security checks within your TSO/E applications if you wish in a variety of ways, such as exits. 7. You can accomplish #6 with the ingredients available with your base z/OS license if you wish. (Certificate Express Logon may require the z/OS Security Server.) Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On 20 July 2012 05:06, Timothy Sipples timothy.sipp...@us.ibm.com wrote: 3. TSO/E is a part of z/OS, but most people who use z/OS these days probably aren't using TSO/E. Well, it depends what you measure... When I use my bank's ATM, I am using z/OS, and the bank has several million customers, so indeed the portion of TSO/E users at the bank is tiny. And this was always true; even in the old days at most shops TSO[/E] was not how most computer users interacted with the system. Most programmers and operations staff - well perhaps. Are you saying that that is what has changed? That compile/edit/submit and data admin type of work is now mostly not being done with TSO? If so, what is it being done with? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
In ofbece3590.44f08adb-on48257a41.002f9ff5-48257a41.00320...@us.ibm.com, on 07/20/2012 at 05:06 PM, Timothy Sipples timothy.sipp...@us.ibm.com said: I'm not sure I understand the question, There is support for mapping long user ids into short user ids. Does that support work if the access validation is in a third party LDAP server? 1. Unaided, TSO/E supports up to 7 character user IDs. Yes, otherwise there would have been no need to ask the question. 2. Note that you are not required to use TSO/E user IDs as user IDs. You are if you want to log on to TSO foreground, which is what I asked about. 3. TSO/E is a part of z/OS, but most people who use z/OS these days probably aren't using TSO/E. But I explicitly asked about TSO. 5. You can place practically anything you wish in front of TSO/E in a variety of ways to provide additional security challenges before granting access to TSO/E. But can you still remap userids if you do? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On Fri, Jul 20, 2012 at 12:08 PM, Tony Harminc t...@harminc.net wrote: On 20 July 2012 05:06, Timothy Sipples timothy.sipp...@us.ibm.com wrote: 3. TSO/E is a part of z/OS, but most people who use z/OS these days probably aren't using TSO/E. Are you saying that that is what has changed? That compile/edit/submit and data admin type of work is now mostly not being done with TSO? If so, what is it being done with? Tony H. I think that IBM is *hoping* that they'll all start using RDz. We have it our shop, but as far as I can tell there hasn't been a stampede away from TSO/ISPF. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Sales pitch, sorry guys...I will bet there are thousands and thousands of users using either TSO or CMS ..of course CICS and IMS and DB2 ...we also sell software ...LDAP ...but I won't go there unless its offline. This isn't the place to try to hustle ppl Scott ford www.identityforge.com On Jul 20, 2012, at 4:57 PM, Don Leahy don.le...@leacom.ca wrote: On Fri, Jul 20, 2012 at 12:08 PM, Tony Harminc t...@harminc.net wrote: On 20 July 2012 05:06, Timothy Sipples timothy.sipp...@us.ibm.com wrote: 3. TSO/E is a part of z/OS, but most people who use z/OS these days probably aren't using TSO/E. Are you saying that that is what has changed? That compile/edit/submit and data admin type of work is now mostly not being done with TSO? If so, what is it being done with? Tony H. I think that IBM is *hoping* that they'll all start using RDz. We have it our shop, but as far as I can tell there hasn't been a stampede away from TSO/ISPF. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Passwords and user-ids was Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On 16 Jul 2012 09:00:40 -0700, in bit.listserv.ibm-main you wrote: The acceptability of length limitations depends upon their values. Passwords or userids that may be at most 8 characters in length are unacceptable today. Has IBM changed that limitation for standard TSO and CICS login. I also have a problem with using special characters in passwords unless I know they are stable across code pages. In EBCDIC the US dollar sign becomes the pound sterling sign in Britain and the yen sign in Japan. If you believe that user-ids should be larger than 7 characters or even 8, then what are the implications for SMF records and various control blocks in z/OS? I think that you have to use LDAP or something similar to have passwords larger than 8 bytes in z/OS. Clark Morris A limitation to at most 2^15 - 1 = 32767 characters is, in my view at least, unobjectionable. Larger limitations like this one are often reflections of control-block overflow problems in some procedural language. These limitations can be circumvented, but the concatenation schemes that do so are very tedious. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
The total value (market capitalization) of Yahoo has steadily declined over the past several years. Maybe they could try something different, like protecting their users' mailboxes and address books (while they deliver ads to them). Yahoo's fundamental business problem is that they've been losing eyeballs and, thus, all important advertising revenue to other companies, particularly to Google. That's been reflected in their loss of e-mail users, too. If users can't trust Yahoo to keep their private information private -- and they can't if they use Yahoo Mail's Web UI -- then users will continue leaving Yahoo. Fixing that security problem isn't going to solve all of Yahoo's business problems. But it's a prerequisite. Some things you've just got to do simply to keep the lights on, and that's one of them. My views are my own, of course. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
In 886132E644ECAE808EED6EEFA317@graham, on 07/17/2012 at 11:15 AM, Graham Hobbs gho...@cdpwise.net said: When someone uses the underscores between some words .. what does that mean? Underscore. ITYM when somebody uses underscore *around* a word. In that case it means the same as underscoring the word, a form of emphasis. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
In ofae475794.d0761284-on48257a3e.001cb9f7-48257a3e.001fa...@us.ibm.com, on 07/17/2012 at 01:45 PM, Timothy Sipples timothy.sipp...@us.ibm.com said: Most coffee shops, hotels, etc. still don't use encrypted wi-fi. Bletch! I'd better check what my local library uses, if anything. 3. The Internet is a public, untrusted network. Alas, it is a public, untrustworthy network that is nonetheless trusted by all too many. Such as Yahoo :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Use a TOR connection. With that, you have a SSL/TLS encoded connection from your PC to a local TOR router. And it bounces around in the TOR network until it exits for a TOR end point to then go to the actual site you want. The site doesn't know where you came from initially because it only sees the TOR exit point's IP address. All packets are encrypted from your PC to the TOR exit point router. They may (http) then be in clear text or encrypted (https) during the last hop. Which will likely be closer to your destination and therefore harder to intercept than if it were clear text all the way. https://www.torproject.org/docs/tor-doc-windows.html.en -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, July 19, 2012 8:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek In OFAE475794.D0761284-ON48257A3E.001CB9F7-48257A3E.001FA9B9@us. ibm.com, on 07/17/2012 at 01:45 PM, Timothy Sipples timothy.sipp...@us.ibm.com said: Most coffee shops, hotels, etc. still don't use encrypted wi-fi. Bletch! I'd better check what my local library uses, if anything. 3. The Internet is a public, untrusted network. Alas, it is a public, untrustworthy network that is nonetheless trusted by all too many. Such as Yahoo :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
The arguments that Timothy Sipples makes against Paul Gilmartin's begin extract Of course, turn on implies commiting the CPU (micro)cycles to peform the encryption /end extract are, in their way, persuasive; but there is another, non-economic argument that is even more persuasive to some IT managements: you are exposing not just your company but your own jobs to grave danger. Heads roll after each of these security-breach fiascos, and one of them may be yours. John Gilmore, Ashland, MA 01721 - USA On 7/18/12, Timothy Sipples timothy.sipp...@us.ibm.com wrote: Paul Gilmartin writes: Of course, turn on implies commiting the CPU (micro)cycles to peform the encryption. Yes it does. Google and Microsoft (to pick two examples) made the resource commitment years ago, when computing power cost a lot more, and their customers are far more secure. Training airline pilots costs money, too. Putting seat belts in automobiles costs money. Testing a new pharmaceutical costs money. And, again, is that LDAP an LDAP client or an LDAP server. If IT management has decreed that IDs should be managed via LDAP hosted on, e.g., a Linux server, z/OS needs not an LDAP server but an LDAP client in order to play well with others. With such a decision a fait accompli, that management will be little moved by arguments of the technical superiority of Tivoli. It's called Tivoli Directory Server for z/OS. Granted, software names aren't always perfect, but server means server. But yes, it also includes an LDAP client. I'll quote from IBM redbook SG24-7849: The IBM Tivoli Directory Server for z/OS deliverable that ships with the base of z/OS provides a Version 3 LDAP client and server. The z/OS LDAP client contains C APIs and command line utilities used to add, delete, modify, rename, compare, and search entries in an LDAP directory. C APIs are, of course, callable from practically anything -- COBOL, Java, PL/I, Assembler, etc. (There are additional middleware options if you don't even want to do that.) So yes, your z/OS-based applications can access some/any other LDAP V3 server(s) for their authentication and/or authorization needs if that's the way your IT department wants to roll, via exits and/or directly. And that's base z/OS -- every z/OS licensee has that capability today, even if you don't have the z/OS Security Server (RACF). Here's the link to the redbook for more information: http://www.redbooks.ibm.com/redbooks/pdfs/sg247849.pdf You can also use Java as your LDAP client environment on z/OS if you prefer. Java (the IBM SDK) is also a no additional charge feature of base z/OS, and you can use JNDI methods to access LDAP servers (including the Tivoli Directory Server for z/OS). Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Graham Hobbs wrote: When someone uses the underscores between some words .. what does that mean? EMPHASIS. It is one way to put reader's attention to that word(s) without using advanced formatting gizmos. As others have noted, it is a way of [manual] formatting only usable by your tired eyes, not by whatever reader/formatter you're using. Without formatting, how do you write something like these?: 1/3 (0.33) or use a shorter mathematical denotion for that. 4 times 4 = 4^2, you write a small 2 to the right of 4, (superscript and subscript) Square root of say 10. Steve also kindly showed how you write Boldfaced, Underscored and Italicized word(s). And how do you write strikethrough and such formatting without using advanced word processing software? My pet peeve: I hate it that the word ftp is automatically marked [1] as a hypertext link, where I just want mention that word as a verb, but that is just me... ;-D Groete / Greetings Elardus Engelbrecht [1] - yes, I can reverse or disable that, but... Above text (and this sentence! ) was written in Plain Text as used on IBM-MAIN's web page - Send Message page. One of these days, I want to play around with HTML part. But then not everyone can probably read what I wanted to write. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SV: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Interesting. Regards, Thomas Berg ___ Thomas Berg Specialist AM/SMS SWEDBANK AB (publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] För Anne Lynn Wheeler Skickat: den 15 juli 2012 19:18 Till: IBM-MAIN@LISTSERV.UA.EDU Ämne: Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek scott_j_f...@yahoo.com (Scott Ford) writes: Very true..but still I think Yahoo has a responsibility to their customers We were tangentially involved in the cal. data breach notification act (the original notification act) having been brought in to help wordsmith the cal. electornic signature act. several of the participants were involved in privacy issues and had done extensive surveys. the #1 issue from the surveys, was identity theft, primarily the form involving account fraud (fraudulent financial transactions) primarily as result of data breaches. There seemed to be little or nothing being done about the problem and there was some hope that the publicity from the notifications would motivate countermeasures. The issue was security measures are usually taken for self-protection, the problem was that the institutions with the data breaches had little at risk ... it was their clients/customers that were suffering the fraud ... and so they had no motivation to take corrective action. Since then the proposed federal legislation has been about evenly divided between requirements similar to the original cal. bill and those that eliminates most requirements for notifications (sometimes disguised by requiring that breach involve multiple different kinds of personal information that doesn't occur in the real world). The same organizations were in the process of doing a Cal. opt-in privacy bill (institutions can only share personal information when authorized by individual). GLBA is better known for repeal of Glass- Steagall. However the rhetoric on the floor of congress was that the primary purpose of GLBA was to allow those with bank charters to keep them, but prevent anybody else from getting bank charters (eliminate competition). However, another provision in GLBA was opt-out privacy sharing (institutions can share personal information unless they have record of individual objecting; federal preemption of state laws). At 2004 annual privacy conference in DC during panel with FTC commissioners, an individual asked from the floor if the FTC was going to do anything about opt-out. They said they were involved with most of the major financial call-centers and none of the opt-out call lines were equipped to record any information from opt-out calls (so the institutions could claim they could share since there was no record of objections). The major motivation for cyberattacks and breaches has been being able to use stolen account info for fraudulent financial transactions. A problem is the business process is severely misaligned. The value of the information to the merchant is profit on the transaction (possibly couple dollars; for transaction processor possibly a few cents). The value of the information to the crook is the account balance and/or credit limit. As a result the attackers may be able to outspend by a factor of 100 times (what the defenders can afford to spend on security measures). The account information is also required in dozens of business processes at millions of locations on the planet. At the same time the threat of fraudulent transactions requires that the account information is kept confidential and never divulged. We've claimed that with the diametrically opposing requirements, even if the planet was buried under miles of information hiding encryption, it still wouldn't be able to stop information leakage. In the past, the merchants have been told that a large part of the interchange fee (value subtracted from amount received by merchants) has been tightly tied to the respective fraud rates ... resulting in studies that financial infrastructure makes a large profit from fraudulent transactions ... eliminating any motivation to change the paradigm and correctly aligned the business process to eliminate fraud. Futhermore, crooks would likely move attacks to the next lowest hanging part of the financial infrastructure (which doesn't involve merchants; no justification to charge hefty profit fee whenever there are fraudulent losses). -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On Tue, 17 Jul 2012 13:45:51 +0800, Timothy Sipples wrote: 4. It's a big problem when practically everybody in the security community criticizes Yahoo! for their intransigence in fixing the problem. It's an even bigger problem when my own mother suffered from Yahoo's decade plus long failure to turn on HTTPS. Of course, turn on implies commiting the CPU (micro)cycles to peform the encryption. (*) It would certainly help if the wi-fi industry adopted a Public WPA2 (a.k.a. coffee shop) addition to their standards, requiring adoption and compliance among manufacturers. Such an amendment would be similar to HTTPS, allowing simple walk up encryption of wi-fi connections. Hopefully it would also have reputation-based client evaluation of wi-fi hotspots to reduce spoofing risk. Oddly, wi-fi doesn't yet have a great, easy-to-use security solution for the coffee shop/hotel scenarios where wi-fi is so popular. Maybe Apple will figure this out. And WEP/WPA provides encryption as far as the coffee shop's router. Upstream from that the communication is still susceptible to interception. And an unscrupulous coffee shop itself could log and mine its traffic. There are enterprises providing VPN services commercially to their hubs, often geographically dispersed. But the VPN provider itself has access to all the customer's traffic. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On Tue, 17 Jul 2012 13:13:03 +0800, Timothy Sipples wrote: You're referring to TSO/E only, which has a 7 character user ID limitation. Yes, if you're shopping for TSO/E, maybe that's a strike against TSO/E. Also (consequently?) if you're shopping for a Lockheed Martin F-22 Raptor military fighter aircraft. Its design support and parts database is limited to 7 character user IDs, too: http://www.lockheedmartin.com/us/aeronautics/materialmanagement/scm-engineering/scm-emap.html I suppose that's some kind of endorsement. The (consequently?) may be significant. Fact: Every z/OS licensee receives Tivoli Directory Server for z/OS with LDAP. There's no such limit there, and, like TSO/E, it's part of base z/OS. If you want N-character user IDs (N7), go for it. Enjoy. But do users with such IDs then have access to TSO/E? And how do IDs with N8 play with other components, such as batch? For simple examples, what ID is displayed in messages such as IRR010I? What ID does getpwuid() return as *pw_name? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Tuesday, July 17, 2012 12:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek snip Fact: Every z/OS licensee receives Tivoli Directory Server for z/OS with LDAP. There's no such limit there, and, like TSO/E, it's part of base z/OS. If you want N-character user IDs (N7), go for it. Enjoy. Hum, I didn't know we had Tivoli Directory Server built into and free to use with z/OS. I may give a look at this. It __might__ be of some interest. But not really likely, given the MS-centric world view of everybody here who is not directly using z/OS. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On Tue, 17 Jul 2012 07:36:49 -0500, McKown, John wrote: -Original Message- [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Tuesday, July 17, 2012 12:13 AM snip Fact: Every z/OS licensee receives Tivoli Directory Server for z/OS with LDAP. There's no such limit there, and, like TSO/E, it's part of base z/OS. If you want N-character user IDs (N7), go for it. Enjoy. Hum, I didn't know we had Tivoli Directory Server built into and free to use with z/OS. I may give a look at this. It __might__ be of some interest. But not really likely, given the MS-centric world view of everybody here who is not directly using z/OS. And, again, is that LDAP an LDAP client or an LDAP server. If IT management has decreed that IDs should be managed via LDAP hosted on, e.g., a Linux server, z/OS needs not an LDAP server but an LDAP client in order to play well with others. With such a decision a fait accompli, that management will be little moved by arguments of the technical superiority of Tivoli. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
For me (and I think that I'm the only one who does it), it is just for EMPHASIS, instead of capitalizing or doing a emBOLD/em. It is not any kind of real or defacto standard. Just an oddity on my part. Due mainly to my hatred of using HTML formatted email. It's not that I actually dislike HTML in general. I just despise some people's choices of fonts (like 6 point script, which I just can't read well) and wacky use of color (why do people use light yellow on light blue? like the nitwit who, years ago, put her font color to dark blue on black and the complained that she couldn't read the screen any more.) -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Graham Hobbs Sent: Tuesday, July 17, 2012 10:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek When someone uses the underscores between some words .. what does that mean? Thanks Graham Hobbs - Original Message - From: McKown, John john.mck...@healthmarkets.com Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 17, 2012 8:36 AM Subject: Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Tuesday, July 17, 2012 12:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek snip Fact: Every z/OS licensee receives Tivoli Directory Server for z/OS with LDAP. There's no such limit there, and, like TSO/E, it's part of base z/OS. If you want N-character user IDs (N7), go for it. Enjoy. Hum, I didn't know we had Tivoli Directory Server built into and free to use with z/OS. I may give a look at this. It __might__ be of some interest. But not really likely, given the MS-centric world view of everybody here who is not directly using z/OS. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On 7/17/2012 9:21 AM, McKown, John wrote: For me (and I think that I'm the only one who does it), it is just for EMPHASIS, instead of capitalizing or doing a emBOLD/em. It is not any kind of real or defacto standard. Just an oddity on my part. Due mainly to my hatred of using HTML formatted email. It's not that I actually dislike HTML in general. I just despise some people's choices of fonts (like 6 point script, which I just can't read well) and wacky use of color (why do people use light yellow on light blue? like the nitwit who, years ago, put her font color to dark blue on black and the complained that she couldn't read the screen any more.) You're not the only one. I have found that _one_ underscore before and after a word displays as underline on many (most? all?) mail clients. So I use that underline as an emphasis while still eschewing sending HTML email. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * Special promotion: 15% off on all DB2 training classes scheduled by September 1, taught by year end 2011 * Check out our entire DB2 curriculum at: http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Paul Gilmartin writes: Of course, turn on implies commiting the CPU (micro)cycles to peform the encryption. Yes it does. Google and Microsoft (to pick two examples) made the resource commitment years ago, when computing power cost a lot more, and their customers are far more secure. Training airline pilots costs money, too. Putting seat belts in automobiles costs money. Testing a new pharmaceutical costs money. And, again, is that LDAP an LDAP client or an LDAP server. If IT management has decreed that IDs should be managed via LDAP hosted on, e.g., a Linux server, z/OS needs not an LDAP server but an LDAP client in order to play well with others. With such a decision a fait accompli, that management will be little moved by arguments of the technical superiority of Tivoli. It's called Tivoli Directory Server for z/OS. Granted, software names aren't always perfect, but server means server. But yes, it also includes an LDAP client. I'll quote from IBM redbook SG24-7849: The IBM Tivoli Directory Server for z/OS deliverable that ships with the base of z/OS provides a Version 3 LDAP client and server. The z/OS LDAP client contains C APIs and command line utilities used to add, delete, modify, rename, compare, and search entries in an LDAP directory. C APIs are, of course, callable from practically anything -- COBOL, Java, PL/I, Assembler, etc. (There are additional middleware options if you don't even want to do that.) So yes, your z/OS-based applications can access some/any other LDAP V3 server(s) for their authentication and/or authorization needs if that's the way your IT department wants to roll, via exits and/or directly. And that's base z/OS -- every z/OS licensee has that capability today, even if you don't have the z/OS Security Server (RACF). Here's the link to the redbook for more information: http://www.redbooks.ibm.com/redbooks/pdfs/sg247849.pdf You can also use Java as your LDAP client environment on z/OS if you prefer. Java (the IBM SDK) is also a no additional charge feature of base z/OS, and you can use JNDI methods to access LDAP servers (including the Tivoli Directory Server for z/OS). Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Yahoo! Mail -- the Web version -- *still* does not use HTTPS for most communications AFAIK. For example, if you're using a free wi-fi hotspot at a coffee shop, and you access Yahoo! Mail via their Web interface, practically everything except your login credentials flows in the clear. A fairly unsophisticated attacker can intercept that traffic and spoof your browser -- and access all your e-mail -- for up to 7 calendar days (the default timeout). Security professionals have been warning Yahoo! and criticizing them for a decade. Google Mail and Microsoft Hotmail, among others, don't have the problem. (Google has always encrypted its Web UI for e-mail.) Yes, implementing HTTPS costs money. So do security breaches! In short, don't access Yahoo! Mail over any network that you don't trust -- or, better yet, don't access Yahoo! Mail over the Web at all. Access via IMAP -- iPhone or iPad, as examples -- using the built-in mail client is encrypted. Access via the free Zimbra Desktop software is also encrypted, to pick another example. Or don't use Yahoo! Mail at all. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Back to basics: My pet peeve(s) (serious security concerns) are: 1) sites which do not allow use of the full set of special characters. My banks, Google and Facebook do, so it is not that hard. The more posibilities for each character, the more secure the password. 2) sites which limit length of userid and/or password. That's just plain dumb. I avoid such sites figuring that if they are that lazy/stupid, my information is certainly at risk -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
The acceptability of length limitations depends upon their values. Passwords or userids that may be at most 8 characters in length are unacceptable today. A limitation to at most 2^15 - 1 = 32767 characters is, in my view at least, unobjectionable. Larger limitations like this one are often reflections of control-block overflow problems in some procedural language. These limitations can be circumvented, but the concatenation schemes that do so are very tedious. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
In of481ed85f.720f607e-on48257a3d.00242269-48257a3d.0026c...@us.ibm.com, on 07/16/2012 at 03:03 PM, Timothy Sipples timothy.sipp...@us.ibm.com said: Yahoo! Mail -- the Web version -- *still* does not use HTTPS for most communications AFAIK. For example, if you're using a free wi-fi hotspot at a coffee shop, and you access Yahoo! Mail via their Web interface, practically everything except your login credentials flows in the clear. A fairly unsophisticated attacker can intercept that traffic and spoof your browser -- and access all your e-mail -- for up to 7 calendar days (the default timeout). Are you still using Wired Equivalent Privacy (WEP) or something more modern, e.g., Wi-Fi Protected Access (WPA)? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
john_matt...@ea.epson.com (John Mattson) writes: Back to basics: My pet peeve(s) (serious security concerns) are: 1) sites which do not allow use of the full set of special characters. My banks, Google and Facebook do, so it is not that hard. The more posibilities for each character, the more secure the password. 2) sites which limit length of userid and/or password. That's just plain dumb. re: http://www.garlic.com/~lynn/2012j.html#47 Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek http://www.garlic.com/~lynn/2012j.html#53 Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek somebody in POK sent me a copy of Corporate Directive on Passwords late Friday and I redistributed. Over the weekend, somebody printed on 6670 (ibm copier3 with computer interface) on corporate letterhead paper on placed it in all the building corporate bulletin boards. Monday morning numerous people were caught ... even tho the date is clearly sunday and no real corporate directives are dated sunday. Corporate password rules from long ago and far away http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM. http://www.garlic.com/~lynn/2001d.html#53 April Fools Day static, shared secrets were somewhat acceptable for authentication 40yrs ago when a person only had a few. corporate rules were put in place to create impossible to guess (therefor impossible to remember) shared secrets for authentication (with frequent changes) ... as if it was the only authentication the person has to deal with. With the proliferation of static, shared secrets paradigm as authentication mechanism (pins, passwords, etc) ... it isn't uncommon for an individual to have large scores or hundreds (of impossible to remember values). Furthermore, safe security practices require a unique shared secret for every unique security domain (as countermeasure to cross-domain attacks). misc. past posts discussing static shared-secret authentication http://www.garlic.com/~lynn/subintegrity.html#secrets misc. past posts discussing internet/network based authentication using non-static data (countermeasure to harvesting and reply attacks) for kerberos http://www.garlic.com/~lynn/subpubkey.html#kerberos similar discussions for radius http://www.garlic.com/~lynn/subpubkey.html#radius ... aka simple registration of public key in lieu of password ... w/o the enormous complexity and points of failure introduced by digital certificates and PKIs ... misc. past posts discussing non-certificate based public key authentication http://www.garlic.com/~lynn/subpubkey.html#certless -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On Mon, Jul 16, 2012 at 12:00 PM, John Gilmore jwgli...@gmail.com wrote: The acceptability of length limitations depends upon their values. Passwords or userids that may be at most 8 characters in length are unacceptable today. Passwords, yes; userids, meh -- I don't consider a userid to be a secure data point. A limitation to at most 2^15 - 1 = 32767 characters is, in my view at least, unobjectionable. Larger limitations like this one are often reflections of control-block overflow problems in some procedural language. These limitations can be circumvented, but the concatenation schemes that do so are very tedious. Seriously? You have 32K passwords? Or is that a Nah, nobody would ever want anything CLOSE to this, so let's use this and forget about it value? (I'm tempted to quote the 64K is enough thing, but this is clearly different, since no human would ever use keys that large!) Or are you thinking of machine-to-machine interactions, which might indeed use very long keys (though I don't want to have to deal with them when they break)? -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Perhaps 8 character passwords should be replaced with 255 characters passphases (password phases) ? Steve Finch -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, July 16, 2012 1:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek On Mon, 16 Jul 2012 12:00:33 -0400, John Gilmore wrote: Passwords or userids that may be at most 8 characters in length are unacceptable today. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
The 32 kib bound has two rationales: 1) It is enough/overkill for passwords used by people and 2) larger values are problematic, produce control-block overflows, in some contexts. The first of these two is the more important. The practice of Increasing the supported length of something from 8 to 16 to 32 to . . . is a preposterous one that needs to be avoided. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
You mandate any policy you want, try enforcing password rules Scott ford www.identityforge.com On Jul 16, 2012, at 1:39 PM, Finch, Steve (ES - Mainframe) steve.fi...@hp.com wrote: Perhaps 8 character passwords should be replaced with 255 characters passphases (password phases) ? Steve Finch -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, July 16, 2012 1:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek On Mon, 16 Jul 2012 12:00:33 -0400, John Gilmore wrote: Passwords or userids that may be at most 8 characters in length are unacceptable today. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On Mon, Jul 16, 2012 at 4:15 PM, John Gilmore jwgli...@gmail.com wrote: We have begun to see fallout. Fortunately, it's amateurish so far. This moring my wife received an email, a long litany of woe and injuries, allegedly from an old friend and college classmate. She wanted us to send money to her in Spain. Called, it turned out that she was in good health at home in Wellesley. She thanked Kate for her concern, and I emailed her with some advice on how to recover from having her email accounts hacked. I've heard of folks who've fallen for this. What I can't imagine is the confluence of someone who I know well enough to blindly send money to AND think I'd be high enough on their list of folks to email AND wouldn't know that they were overseas already AND don't have someone I'd call immediately to ask Have you heard from Joe?. Who has people in that category?! Mind you, if someone got hacked through browser spoofing in an Internet cafe *while overseas*, it would be a lot more plausible. The fact that this isn't the normal MO suggests that the much-vaunted browser spoofing isn't nearly as easy as folks make it sound... -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
zedgarhoo...@gmail.com (zMan) writes: I've heard of folks who've fallen for this. What I can't imagine is the confluence of someone who I know well enough to blindly send money to AND think I'd be high enough on their list of folks to email AND wouldn't know that they were overseas already AND don't have someone I'd call immediately to ask Have you heard from Joe?. Who has people in that category?! Mind you, if someone got hacked through browser spoofing in an Internet cafe *while overseas*, it would be a lot more plausible. The fact that this isn't the normal MO suggests that the much-vaunted browser spoofing isn't nearly as easy as folks make it sound... re: http://www.garlic.com/~lynn/2012j.html#47 Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek http://www.garlic.com/~lynn/2012j.html#53 Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek http://www.garlic.com/~lynn/2012j.html#54 Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek one of the issues is whether there is better low-hanging fruit 95-96 time-period ... there were industry presentations by dial-up consumer online banking regarding motivation for moving to the internet (top of the list was enormous consumer support costs for serial-port dial-up modems ... being able to offload to ISPs). At the same time, the dial-up commerical/cash-management online banking operations were saying that they would *NEVER* move to the internet because of a long list of security vulnerabilities (nearly all of which have since been seen). the commercial operations eventually started moving to the internet (anyway ... possibly loss of institutional knowledge in the industry) and started seeing all the vulnerabilities that had been predicted. some of this has shown up recently in court cases where business operations have lost hundreds of thousands or millions from their accounts in such attacks ... and they are suing the financial institutions for the loss on the grounds of providing inadequate security. recent posts in (linkedin) Financial Crime Risk, Fraud and Security discussions: http://www.garlic.com/~lynn/2012i.html#18 Zeus/SpyEye 'Automatic Transfer' Module Masks Online Banking Theft http://www.garlic.com/~lynn/2012i.html#32 Zeus/SpyEye 'Automatic Transfer' Module Masks Online Banking Theft http://www.garlic.com/~lynn/2012j.html#0 Federal appeal court raps bank over shoddy online security http://www.garlic.com/~lynn/2012j.html#8 Federal appeal court raps bank over shoddy online security related news URL references: Zeus/SpyEye 'Automatic Transfer' Module Masks Online Banking Theft; Automated attack bypasses two-factor authentication http://www.darkreading.com/authentication/167901072/security/attacks-breaches/240002267/zeus-spyeye-automatic-transfer-module-masks-online-banking-theft Cyber crooks evading advanced bank security to transfer funds http://www.scmagazine.com/cyber-crooks-evading-advanced-bank-security-to-transfer-funds/article/246227/ Exclusive: Online bank-theft software grows more sophisticated http://news.yahoo.com/exclusive-online-bank-theft-software-grows-more-sophisticated-080445057--sector.html Online bank-theft software grows more sophisticated http://www.chicagotribune.com/business/breaking/chi-online-banktheft-software-grows-more-sophisticated-20120618,0,278609.story Fake Android antivirus app likely linked to Zeus banking Trojan, researchers say; Cybercriminals are distributing a mobile component of the Zeus banking Trojan as an Android security application, Kaspersky experts said http://www.networkworld.com/news/2012/061912-fake-android-antivirus-app-likely-260331.html Federal appeal court raps bank over shoddy online security http://www.networkworld.com/news/2012/070512-federal-appeal-court-raps-bank-260672.html ENISA Warns Banks: Assume All PCs Are Infected http://news.softpedia.com/news/ENISA-Warns-Banks-Assume-All-PCs-Are-Infected-279470.shtml Court Slams Bank For Ignoring Zeus Attack http://www.informationweek.com/news/security/attacks/240003172 Zeus: How to Fight Back; Sophisticated Trojan Demands New Game Plan http://www.bankinfosecurity.com/interviews/zeus-how-to-fight-back-i-1592?rf=2012-07-06-eb Cybercrooks preying on small businesses http://nakedsecurity.sophos.com/2012/07/06/cybercrooks-preying-on-small-businesses/ -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On Mon, 16 Jul 2012 13:31:07 -0400, zMan wrote: On Mon, Jul 16, 2012 at 12:00 PM, John Gilmore wrote: Passwords or userids that may be at most 8 characters in length are unacceptable today. Passwords, yes; userids, meh -- I don't consider a userid to be a secure data point. It's not a matter of security; rather that many IT departments nowadays have a standard of 8-character userids. IBM is a tail that can no longer wag that dog; the CIO can cite refusal to comply with corporate standards as one more strike against z/OS in a purchase decision. And ID administration must be via LDAP from the corporate standard Linux server. There are 3rd party products that enable this; none AFAIK for 8-character userids. Hmm... what's the length limit of aliases in USERIDALIASTABLE? Is USERIDALIASTABLE processed for connections to FTP server, or only for logins? Does it affect the output of getpwuid()? Etc.? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxzb2c0/3.7.4.5 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Paul Gilmartin writes: It's not a matter of security; rather that many IT departments nowadays have a standard of 8-character userids. IBM is a tail that can no longer wag that dog; the CIO can cite refusal to comply with corporate standards as one more strike against z/OS in a purchase decision. You're referring to TSO/E only, which has a 7 character user ID limitation. Yes, if you're shopping for TSO/E, maybe that's a strike against TSO/E. Also (consequently?) if you're shopping for a Lockheed Martin F-22 Raptor military fighter aircraft. Its design support and parts database is limited to 7 character user IDs, too: http://www.lockheedmartin.com/us/aeronautics/materialmanagement/scm-engineering/scm-emap.html Fact: Every z/OS licensee receives Tivoli Directory Server for z/OS with LDAP. There's no such limit there, and, like TSO/E, it's part of base z/OS. If you want N-character user IDs (N7), go for it. Enjoy. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Shmuel Metz asks: Are you still using Wired Equivalent Privacy (WEP) or something more modern, e.g., Wi-Fi Protected Access (WPA)? Of course I use the latter, but a few points: 1. Wi-fi encryption only handles the hop between your wireless device and the wireless router/access point. Beyond that almost everything Yahoo! Mail's Web UI transmits (and receives) is in the clear via HTTP not HTTPS. 2. I specifically mentioned coffee shops. Most coffee shops, hotels, etc. still don't use encrypted wi-fi.(*) 3. The Internet is a public, untrusted network. It is not a private, secured network. Everything you send and receive via Yahoo! Mail's Web UI flows in the clear with the exception of your login credentials which are checked (by default) only once every 7 days. Anybody between you and Yahoo! can intercept that unencrypted traffic -- the hotel, the coffee shop, the ISPs, governments, an employer, etc., etc. Spammers are already sifting through that unencrypted data to capture e-mail addresses and other information. Your inbox, every e-mail you read, every e-mail you write, and your entire address book are all wide open to anyone who can intercept the Web UI network traffic at any point. 4. It's a big problem when practically everybody in the security community criticizes Yahoo! for their intransigence in fixing the problem. It's an even bigger problem when my own mother suffered from Yahoo's decade plus long failure to turn on HTTPS. (*) It would certainly help if the wi-fi industry adopted a Public WPA2 (a.k.a. coffee shop) addition to their standards, requiring adoption and compliance among manufacturers. Such an amendment would be similar to HTTPS, allowing simple walk up encryption of wi-fi connections. Hopefully it would also have reputation-based client evaluation of wi-fi hotspots to reduce spoofing risk. Oddly, wi-fi doesn't yet have a great, easy-to-use security solution for the coffee shop/hotel scenarios where wi-fi is so popular. Maybe Apple will figure this out. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On Sun, Jul 15, 2012 at 12:18 AM, Ed Gould edgould1...@comcast.net wrote: http://www.informationweek.**com/news/security/attacks/** 240003692?cid=nl_IW_daily_**2012-07-13_htmlelq=** ce8b95a547134f1eb898ba0413ba0b**0chttp://www.informationweek.com/news/security/attacks/240003692?cid=nl_IW_daily_2012-07-13_htmlelq=ce8b95a547134f1eb898ba0413ba0b0c They missed Don't use Yahoo :-) -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Hey zMan, Very true..but still I think Yahoo has a responsibility to their customers Scott ford www.identityforge.com On Jul 15, 2012, at 10:43 AM, zMan zedgarhoo...@gmail.com wrote: On Sun, Jul 15, 2012 at 12:18 AM, Ed Gould edgould1...@comcast.net wrote: http://www.informationweek.**com/news/security/attacks/** 240003692?cid=nl_IW_daily_**2012-07-13_htmlelq=** ce8b95a547134f1eb898ba0413ba0b**0chttp://www.informationweek.com/news/security/attacks/240003692?cid=nl_IW_daily_2012-07-13_htmlelq=ce8b95a547134f1eb898ba0413ba0b0c They missed Don't use Yahoo :-) -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
On Sun, Jul 15, 2012 at 12:12 PM, Scott Ford scott_j_f...@yahoo.com wrote: Hey zMan, Very true..but still I think Yahoo has a responsibility to their customers Absolutely. Though this gets into a related issue: what do free services owe their customers? I'm not satisfied with the current answer of nothing: they're able to make money off their real customers (advertisers) because their free customers exist. So the pure capitalist answer of If they screw the freebies they'll fail isn't quite sufficient. But I'm not sure what the right answer is. -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
scott_j_f...@yahoo.com (Scott Ford) writes: Very true..but still I think Yahoo has a responsibility to their customers We were tangentially involved in the cal. data breach notification act (the original notification act) having been brought in to help wordsmith the cal. electornic signature act. several of the participants were involved in privacy issues and had done extensive surveys. the #1 issue from the surveys, was identity theft, primarily the form involving account fraud (fraudulent financial transactions) primarily as result of data breaches. There seemed to be little or nothing being done about the problem and there was some hope that the publicity from the notifications would motivate countermeasures. The issue was security measures are usually taken for self-protection, the problem was that the institutions with the data breaches had little at risk ... it was their clients/customers that were suffering the fraud ... and so they had no motivation to take corrective action. Since then the proposed federal legislation has been about evenly divided between requirements similar to the original cal. bill and those that eliminates most requirements for notifications (sometimes disguised by requiring that breach involve multiple different kinds of personal information that doesn't occur in the real world). The same organizations were in the process of doing a Cal. opt-in privacy bill (institutions can only share personal information when authorized by individual). GLBA is better known for repeal of Glass-Steagall. However the rhetoric on the floor of congress was that the primary purpose of GLBA was to allow those with bank charters to keep them, but prevent anybody else from getting bank charters (eliminate competition). However, another provision in GLBA was opt-out privacy sharing (institutions can share personal information unless they have record of individual objecting; federal preemption of state laws). At 2004 annual privacy conference in DC during panel with FTC commissioners, an individual asked from the floor if the FTC was going to do anything about opt-out. They said they were involved with most of the major financial call-centers and none of the opt-out call lines were equipped to record any information from opt-out calls (so the institutions could claim they could share since there was no record of objections). The major motivation for cyberattacks and breaches has been being able to use stolen account info for fraudulent financial transactions. A problem is the business process is severely misaligned. The value of the information to the merchant is profit on the transaction (possibly couple dollars; for transaction processor possibly a few cents). The value of the information to the crook is the account balance and/or credit limit. As a result the attackers may be able to outspend by a factor of 100 times (what the defenders can afford to spend on security measures). The account information is also required in dozens of business processes at millions of locations on the planet. At the same time the threat of fraudulent transactions requires that the account information is kept confidential and never divulged. We've claimed that with the diametrically opposing requirements, even if the planet was buried under miles of information hiding encryption, it still wouldn't be able to stop information leakage. In the past, the merchants have been told that a large part of the interchange fee (value subtracted from amount received by merchants) has been tightly tied to the respective fraud rates ... resulting in studies that financial infrastructure makes a large profit from fraudulent transactions ... eliminating any motivation to change the paradigm and correctly aligned the business process to eliminate fraud. Futhermore, crooks would likely move attacks to the next lowest hanging part of the financial infrastructure (which doesn't involve merchants; no justification to charge hefty profit fee whenever there are fraudulent losses). -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
ZMan, Very true. Scott ford www.identityforge.com On Jul 15, 2012, at 12:53 PM, zMan zedgarhoo...@gmail.com wrote: On Sun, Jul 15, 2012 at 12:12 PM, Scott Ford scott_j_f...@yahoo.com wrote: Hey zMan, Very true..but still I think Yahoo has a responsibility to their customers Absolutely. Though this gets into a related issue: what do free services owe their customers? I'm not satisfied with the current answer of nothing: they're able to make money off their real customers (advertisers) because their free customers exist. So the pure capitalist answer of If they screw the freebies they'll fail isn't quite sufficient. But I'm not sure what the right answer is. -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
I agree whether its YAHOO or whoever stole the passwords it was bad form. I am trying to remember if at one time (its not that way now) RACF didn't do the same (passwords in display form). My memory only goes back just so far and it doesn't reveal anything. Does anyone remember when RACF was changed to scramble the password? Ed On Jul 15, 2012, at 12:52 AM, Scott Ford wrote: Ed, I skimmed the below article. I agree with what they say, we are in the security business. I think the punishment of the perps should be severe enough to deter hacking like that. Maybe I am too old school. They should be held accountable for their actions. Scott ford www.identityforge.com On Jul 15, 2012, at 12:18 AM, Ed Gould edgould1...@comcast.net wrote: http://www.informationweek.com/news/security/attacks/240003692? cid=nl_IW_daily_2012-07-13_htmlelq=ce8b95a547134f1eb898ba0413ba0b0c - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM- MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
http://www.informationweek.com/news/security/attacks/240003692? cid=nl_IW_daily_2012-07-13_htmlelq=ce8b95a547134f1eb898ba0413ba0b0c -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
Ed, I skimmed the below article. I agree with what they say, we are in the security business. I think the punishment of the perps should be severe enough to deter hacking like that. Maybe I am too old school. They should be held accountable for their actions. Scott ford www.identityforge.com On Jul 15, 2012, at 12:18 AM, Ed Gould edgould1...@comcast.net wrote: http://www.informationweek.com/news/security/attacks/240003692?cid=nl_IW_daily_2012-07-13_htmlelq=ce8b95a547134f1eb898ba0413ba0b0c -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
