<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Design&gt;Web Design&gt;Security</title>	<link>http://tc.eserver.org/dir/Design/Web-Design/Security</link>
	<description>A listing of the most recently indexed works about Design and Web Design and Security in the field of technical communication.</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Design&gt;Web Design&gt;Security</title>
		<link>http://tc.eserver.org/dir/Design/Web-Design/Security</link>
	</image>
	<item>
		<title>Stop Password Masking</title>
		<link>http://tc.eserver.org/34891.html</link>
		<guid>http://tc.eserver.org/34891.html</guid>
		<description>Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn&apos;t even increase security, but it does cost you business due to login failures.</description>
	</item>
	<item>
		<title>パスワードを隠すのをやめよう</title>
		<link>http://tc.eserver.org/34892.html</link>
		<guid>http://tc.eserver.org/34892.html</guid>
		<description>ユーザがパスワードを打ち込んでも、黒い点の列でしかフィードバックが返ってこないとき、ユーザビリティは損なわれている。パスワードを隠したからといって、セキュリティは強化されないことが多く、逆に、ログインの失敗によって、あなたのビジネスに悪影響を及ぼす。 </description>
	</item>
	<item>
		<title>A Large-Scale Study of Web Password Habits</title>
		<link>http://tc.eserver.org/34187.html</link>
		<guid>http://tc.eserver.org/34187.html</guid>
		<description>We report the results of a large scale study of password use and password re-use habits. The study involved half a million users over a three month period. A client component on users’ machines recorded a variety of password strength, usage and frequency metrics. This allows us to measure or estimate such quantities as the average number of passwords and average number of accounts each user has, how many passwords she types per day, how often passwords are shared among sites, and how often they are forgotten. We get extremely detailed data on password strength, the types and lengths of passwords chosen, and how they vary by site. The data is the ﬁrst large scale study of its kind, and yields numerous other insights into the role the passwords play in users’ online experience.</description>
	</item>
	<item>
		<title>CAPTCHAs, CAPTCHAs Everywhere</title>
		<link>http://tc.eserver.org/34147.html</link>
		<guid>http://tc.eserver.org/34147.html</guid>
		<description>My business and passion is accessibility and there is obviously a huge problem with these visual CAPTCHAs. If you used alt-text on this image, alt=&quot;e3TJ6Jdp&quot;, that would be fine and very welcome for blind visitors. It would also be welcome for any computer system seeking to sign up for lots of emails. Using alt-text on the image does not solve the problem! The visual image CAPTCHA is fundamentally inaccessible. For the example above, this means very simply that Yahoo excludes people who are blind (or vision impaired) from signing up for Yahoo email accounts.</description>
	</item>
	<item>
		<title>Evaluating Existing Audio CAPTCHAs and an Interface  Optimized for Non-Visual Use</title>
		<link>http://tc.eserver.org/34148.html</link>
		<guid>http://tc.eserver.org/34148.html</guid>
		<description>Audio CAPTCHAs were introduced as an accessible alternative for those unable to use the more common visual CAPTCHAs, but anecdotal accounts have suggested that they may be more difficult to solve. This paper demonstrates in a large study of more than 150 participants that existing audio CAPTCHAs are clearly more difficult and time-consuming to complete as compared to visual CAPTCHAs for both blind and sighted users. In order to address this concern, we developed and evaluated a new interface for solving CAPTCHAs optimized for non-visual use that can be added in-place to existing audio CAPTCHAs. In a subsequent study, the optimized interface increased the success rate of blind participants by 59% on audio CAPTCHAs, illustrating a broadly applicable principle of accessible design: the most usable audio interfaces are often not direct translations of existing visual interfaces.</description>
	</item>
	<item>
		<title>Enhanced Interoperability for Security of XML Web Services</title>
		<link>http://tc.eserver.org/33743.html</link>
		<guid>http://tc.eserver.org/33743.html</guid>
		<description>Enterprises are adopting Web Services to ease application integration across heterogeneous environments within and across security domain boundaries. Security is an important element for the adoption of Web Services. The Organization for the Advancement of Structured Information Standards (OASIS) has recently ratified the Web Services Security standards (Web Services Security: SOAP Message Security 1.0 (WS-Security 2004 ), Web Services Security: UsernameToken Profile 1.0 , and Web Services Security: X.509 Certificate Token Profile ) to provide an extensible framework for providing message integrity, confidentiality, identity propagation, and authentication. The Web Services Interoperability Organization (WS-I) is profiling standards to provide guidelines for implementation and use of relevant standards to enhance interoperability. This paper describes the activities of the WS-I Basic Security Profile (BSP) Working Group (WG). This Working Group is chartered to improve interoperability of security technologies for Web Services by profiling the OASIS Web Service Security and HTTP Over TLS standards. This interoperability profile (known as the Basic Security Profile 1.0) is an extension of the WS-I Basic Profile . The WS-I Basic Profile addresses interoperability for implementations of core Web Services standards.</description>
	</item>
	<item>
		<title>Captcha Usability Revisited: Google Inaccessible to Blind People</title>
		<link>http://tc.eserver.org/32848.html</link>
		<guid>http://tc.eserver.org/32848.html</guid>
		<description>An online petition is being circulated to all Internet users for the purpose of collecting signatures showing support for Google to make its word verification scheme accessible to the blind and visually impaired.</description>
	</item>
	<item>
		<title>Seven Habits for Writing Secure PHP Applications</title>
		<link>http://tc.eserver.org/32704.html</link>
		<guid>http://tc.eserver.org/32704.html</guid>
		<description>Security in a PHP application includes remote and local security concerns. Discover the habits PHP developers should get into to implement Web applications that have both characteristics.</description>
	</item>
	<item>
		<title>How They Hack Your Website: Overview of Common Techniques</title>
		<link>http://tc.eserver.org/32535.html</link>
		<guid>http://tc.eserver.org/32535.html</guid>
		<description>We hear the same terms bandied about whenever a popular site gets hacked. You know… SQL Injection, cross site scripting, that kind of thing. But what do these things mean? Is hacking really as inaccessible as many of us imagine; a nefarious, impossibly technical twilight world forever beyond our ken? Not really.</description>
	</item>
	<item>
		<title>Web Security Isn&apos;t Scary!</title>
		<link>http://tc.eserver.org/32074.html</link>
		<guid>http://tc.eserver.org/32074.html</guid>
		<description>Security is the lifeblood of any web application and every online business. No matter how hard you work designing a great site, creating high-end content, building a lively traffic stream, and improving every aspect of your online business, it can easily be stolen away if you aren’t protected.&#xD;&#xD;Protecting your web presence seems like a daunting task, but there are simple solutions that any webmaster can do to increase security of their applications.</description>
	</item>
	<item>
		<title>httplib2: HTTP Persistence and Authentication</title>
		<link>http://tc.eserver.org/31576.html</link>
		<guid>http://tc.eserver.org/31576.html</guid>
		<description>In this latest Restful Web column, Joe Gregorio explains HTTP persistent connections, pipelining, and the sad state of HTTP authentication.</description>
	</item>
	<item>
		<title>The Inaccessibility of CAPTCHA: Alternatives to Visual Turing Tests on the Web</title>
		<link>http://tc.eserver.org/28741.html</link>
		<guid>http://tc.eserver.org/28741.html</guid>
		<description>A common method of limiting access to services made available over the Web is visual verification of a bitmapped image. This presents a major problem to users who are blind, have low vision, or have a learning disability such as dyslexia. This document examines a number of potential solutions that allow systems to test for human users while preserving access by users with disabilities.</description>
	</item>
	<item>
		<title>Minimal-Feedback Hints for Remembering Passwords</title>
		<link>http://tc.eserver.org/28107.html</link>
		<guid>http://tc.eserver.org/28107.html</guid>
		<description>Passwords are a widely used mechanism for user authentication and are thus critical to the security of many systems. Strong passwords (e.g., b5j#Kv!8N) are less vulnerable to attack but at the same time more difficult to remember. Minimal-feedback hints are introduced to support users in remembering their passwords and thereby enabling them to choose stronger passwords.</description>
	</item>
	<item>
		<title>Community Creators, Secure Your Code! Part II</title>
		<link>http://tc.eserver.org/27676.html</link>
		<guid>http://tc.eserver.org/27676.html</guid>
		<description>In part one of this two-part series, we discussed the threat of cross-site scripting in general terms and introduced a number of important security concepts. In part two, we’ll take a more in-depth, hands-on approach: How does an attacker actually exploit the weaknesses found? How can you protect yourself? For reasons of length, we’ll limit our discussion to two specific, representative examples.</description>
	</item>
	<item>
		<title>Community Creators, Secure Your Code!</title>
		<link>http://tc.eserver.org/27550.html</link>
		<guid>http://tc.eserver.org/27550.html</guid>
		<description>Don’t be like MySpace. Protect your community site from malicious cross-site scripting attacks.</description>
	</item>
	<item>
		<title>Mask Your Web Server for Enhanced Security</title>
		<link>http://tc.eserver.org/26333.html</link>
		<guid>http://tc.eserver.org/26333.html</guid>
		<description>Masking or anonymizing a Web server involves removing identifying details that intruders could use to detect your OS and Web server vendor and version.</description>
	</item>
	<item>
		<title>Password Encryption: Rationale and Java Example</title>
		<link>http://tc.eserver.org/26334.html</link>
		<guid>http://tc.eserver.org/26334.html</guid>
		<description>Most of the web sites today have some sort of a registration module where a user is asked to choose a username/password combination. This data gets stored in the database. You might wonder if the password you provide will be kept well-protected (read encrypted). In case you are the person designing such backend registration component, why not give your users peace of mind by encrypting their passwords?</description>
	</item>
	<item>
		<title>PHP Login System with Admin Features</title>
		<link>http://tc.eserver.org/26328.html</link>
		<guid>http://tc.eserver.org/26328.html</guid>
		<description>I have written and am presenting here a complete Login System that can be easily integrated into any website.</description>
	</item>
	<item>
		<title>Smarter Image Hotlinking Prevention</title>
		<link>http://tc.eserver.org/25500.html</link>
		<guid>http://tc.eserver.org/25500.html</guid>
		<description>Tthe usual approaches for preventing hotlinking (hijacking) images have a couple of side effects. This system works much better.</description>
	</item>
	<item>
		<title>An Introduction to Cookies</title>
		<link>http://tc.eserver.org/23606.html</link>
		<guid>http://tc.eserver.org/23606.html</guid>
		<description>Put simply, cookies are &apos;caller ID for the &apos;Net.&apos; They store small pieces of text in your browser and can only be retrieved by the site that stored them in the first place. Although many sites use cookies only for user identification, others developing CD or standalone help and courseware recognize the cookie&apos;s ability to imitate server behavior by generating dynamic HTML content.</description>
	</item>
	<item>
		<title>Encryption Tutorial</title>
		<link>http://tc.eserver.org/22820.html</link>
		<guid>http://tc.eserver.org/22820.html</guid>
		<description>Dishes up the why and how of real-life data encryption, covering PGP and GnuPG, and using PHP and the mcrypt and mhash libraries.</description>
	</item>
	<item>
		<title>Introduction to Web Security</title>
		<link>http://tc.eserver.org/21988.html</link>
		<guid>http://tc.eserver.org/21988.html</guid>
		<description>Computer security is a give and take situation. You can never be safe so long as you offer services. However, without offering services you may as well not have the computer in the first place. Thus, security becomes more about acceptable risk and emergency recovery than impregnability. It is your job to make sure that the cons of a break have far less impact than the pros of having a web site.</description>
	</item>
	<item>
		<title>Password Usability</title>
		<link>http://tc.eserver.org/21100.html</link>
		<guid>http://tc.eserver.org/21100.html</guid>
		<description>Poor password usability can ruin your web registration process. While passwords are a painful fact of life, there are ways to minimize the problems that users face. This article contains suggestions on how to best collect passwords during the registration process, and it will help you determine if you should allow users to save their passwords.</description>
	</item>
	<item>
		<title>Asking for Usernames and Passwords on the Web</title>
		<link>http://tc.eserver.org/18804.html</link>
		<guid>http://tc.eserver.org/18804.html</guid>
		<description>The Web has moved beyond purely open content available to all. We now want to use it to collect and provide information that we want to restrict in some  way – to members, or to staff, or because it is sensitive or personal data. One common method of restricting access is to ask users to enter username and password. Even this simple combination can be a source of annoyance and frustration to users but it does not have to be. This paper compares options for setting up and&#xD;maintaining usernames and passwords, and also shows how to design a screen so that users are guided easily to the correct choices.</description>
	</item>
	<item>
		<title>Security and Human Factors</title>
		<link>http://tc.eserver.org/11868.html</link>
		<guid>http://tc.eserver.org/11868.html</guid>
		<description>A big lie of computer security is that security improves as password complexity increases. In reality, users simply write down difficult passwords, leaving the system vulnerable. Security is better increased by designing for how people actually behave. </description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Design/Web-Design/Security.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>