Ten Windows Password Myths

With all of our advances in security technology, one aspect remains constant: passwords still play a central role in system security. The difficulty with passwords is that all too often they are the easiest security mechanism to defeat. Although we can use technology and policy to make passwords stronger, we are still fighting the weakest point in any system: the human element.
Ultimately the goal is to get users to choose better passwords. However, it is not always clear how to achieve that goal. The problem is that as creative as humans are, we are way too predictable. If I asked you to make a list of totally random words, inevitably some sort of pattern will emerge in your list. Selecting good passwords requires education. System administrators need to be educated and that education needs to be passed on to end users. This article is meant to bring you closer to understanding passwords in Windows 2000 and XP by addressing common password myths.
Myth #1: My Password Hashes Are Safe When Using NTLMv2
Many readers will be familiar with the weaknesses in LanManager (LM) password hashes that made L0phtcrack so popular. NTLM made hashes somewhat stronger by using a longer hash and allowing both upper and lower-case letters. NTLMv2 made even more advances by computing a 128-bit key space and using separate keys for message integrity and confidentiality. It also uses the HMAC-MD5 algorithm for further message integrity. However, Windows 2000 still often sends LM or NTLM hashes over the network and NTLMv2 is also vulnerable to in-transit (also known as replay) attacks. And since LM and NTLM password hashes are still stored in the registry, you will still be vulnerable to attacks against the SAM.
It will still be some time until we are completely free from the grips of LanManager. Until then, do not assume that your password hashes are safe.
Myth #2. Dj#wP3M$c is a Great Password
A common myth is that totally random passwords spit out by password generators are the best passwords. This is not true. While they may in fact be strong passwords, they are usually difficult to remember, slow to type, and sometimes vulnerable to attacks against the password generating algorithm. It is easy to create passwords that are just as strong but much easier to remember by using a few simple techniques. For example, consider the password "Makeit20@password.com". This password utilizes upper and lower-case letters, two numbers, and two symbols. The password is 20 characters long and can be memorized with very little effort; perhaps even by the time you finish this article. Moreover, this password can be typed very fast. The portion "Makeit20" alternates between left and right-handed keys on the keyboard, improving speed, decreasing typos, and decreasing the chances of someone being able to discover your password by watching you (for a list of nearly eight thousand English words that alternate between left and right-handed keys, see http://www.xato.net/downloads/lrwords.txt.)
The best technique for creating complex passwords that are easier to remember is to use data structures that we are accustomed to remembering. Such structures also make it easy to include punctuation characters in the password, as in the e-mail address example used above. Other data structures that are easy to remember are phone numbers, addresses, names, file paths, etc. Consider also that certain elements make things more memorable for us. For example, patterns, repetition, rhymes, humor, and even offensive words all make passwords that we will never forget.
Myth #3. 14 Characters is the Optimal Password Length
With LM, password hashes were split into two separate 7-character hashes. This actually made passwords more vulnerable because a brute-force attack could be performed on each half of the password at the same time. So passwords that were 9 characters long were broken into one 7-character hash and one 2-character hash. Obviously, cracking a 2-character hash did not take long, and the 7-character portion could usually be cracked within hours. Often, the smaller portion could actually be used to assist in the cracking of the longer portion. Because of this, many security professionals determined that optimal password lengths were 7 or 14 characters, corresponding to the two 7-character hashes.
NTLM improved the situation some by using all 14 characters to store the password hash. While this did make things better, NT dialog boxes still limited passwords to a maximum of 14 characters; thus the determination that passwords of exactly 14 characters are the optimal length for the best security.
But things are different with newer versions of Windows. Windows 2000 and XP passwords can now be up to 127 characters in length and so 14 characters is no longer a limit. Furthermore, one little known fact discovered by Urity of SecurityFriday.com is that if a password is fifteen characters or longer, Windows does not even store the LanMan hash correctly. This actually protects you from brute-force attacks against the weak algorithm used in those hashes. If your password is 15 characters or longer, Windows stores the constant AAD3B435B51404EEAAD3B435B51404EE as your LM hash, which is equivalent to a null password. And since your password is obviously not null, attempts to crack that hash will fail.
With this in mind, going longer than 14 characters may be good advice. But if you want to enforce very long passwords using group policy or security templates, don't bother - neither will allow you to set a minimum password length greater than 14 characters.
Myth #4. J0hn99 is a Good Password
While it does pass Windows 2000 complexity requirements, "J0hn99" is not as strong a password as it appears. Most password crackers have rules that can try millions of word variants per second. Replacing the letter "o" with the number "0" and adding a couple numbers is no big deal to a password cracker. Some password crackers have rulesets that can create password combinations well beyond the average user's creativity or patience.
A better approach is to be less predictable. Rather than replacing "o" with "0", try replacing "o" with two characters such as "()" as in "j()hn". And of course, making your password longer will make it even stronger.
Myth #5. Eventually Any Password Can Be Cracked
Although a password may eventually be discovered through some means (such as through a keylogger or through social engineering), it is possible to create a password that cannot be cracked in any reasonable time. If a password is long enough, it will take so long or require so much processing power to crack it that it is essentially the same as being unbreakable (at least for most hackers). So yes, eventually any password can be cracked, but eventually may not fall in your lifetime. So unless you have the Government hacking away at your passwords, chances are you are pretty safe. Of course, advances in computing power may some day make this myth a reality.
Myth #6. Passwords Should be Changed Every 30 Days
Although this may be good advice for some high-risk passwords, it is not the best policy for the average user. Requiring frequent password changes often causes users to develop predictable patterns in their passwords or use other means that will actually decrease the effectiveness of their passwords. It is frustrating to a user to have to constantly think of and remember new passwords every 30 days. Rather than limiting password age, it may be better to focus on stronger passwords and better user awareness. A more realistic time for the average user may be 90-120 days. If you give users more time, you may find it easier to convince them to use better passwords.
Myth #7. You Should Never Write Down Your Password
Although this is often good advice, sometimes it is necessary to write down passwords. Users feel more comfortable creating complex passwords if they are able to write them down somewhere in case they forget. However, it is important to educate users on how to properly write down passwords. A sticky note on the monitor is not a good policy, but storing passwords in a safe or even a locked cabinet may be sufficient. And don't neglect security when it comes time to throw those passwords away, many passwords have been compromised after hitting the garbage dumpsters.
You may want to consider allowing users to save passwords in software-based password storage utilities. These utilities allow a user to store many account passwords in one central location, locked with a master password. If you know the master password, you gain access to your entire list of passwords. But before allowing users to save passwords in such tools, consider the risks: first, it is software-based and therefore can itself become a target of attack, and, second, since it is all based on a single master password, that password becomes a single point of failure for all the user's passwords. The best technique is to combine technology, physical security, and company policy.
Sometimes passwords need to be documented. It’s not uncommon to see a company in a panic because their admin just quit, and he's the only one who knows the server password. You should discourage writing down passwords in many situations, but if writing them down helps or is necessary, be smart about it.
Myth #8: Passwords Cannot Include Spaces
Although most users do not realize it, both Windows 2000 and Windows XP allow spaces in passwords. In fact, if you can view a character in Windows, you can use that character in a password. Therefore, spaces are perfectly valid password characters. However, due to how some applications trim spaces, it is often best not to begin or end your password with a space.
Spaces can actually make it easier for users to come up with more complex passwords. A space is used between words therefore using spaces may encourage users to use more than one word in their passwords.
An interesting fact I recently discovered in my research is that spaces do not fall into any of the categories for Windows password complexity requirements. It is not a number or letter yet does not count as a symbol either. So while it will make your password more complex, it does nothing to help you pass Windows complexity requirements.
And finally, one drawback with spaces is that the spacebar makes a unique noise when tapped. It is not hard to hear when someone uses a space in their password. So use spaces, but don't overuse spaces.
Myth #9: Always Use Passfilt.dll
Passfilt.dll is a component that will enforce strong user passwords. In Windows 2000 and XP it is implemented through the "Passwords must meet complexity requirements" policy. While it is often a good policy to enforce, some users may find it frustrating when their passwords are rejected because they are not complex enough. Even experienced administrators have likely had to enter multiple passwords before finally getting one that does pass complexity requirements. Frustrated users certainly are not going to be giving you or your password policy much support.
If you find users are frustrated with the complexity requirements, perhaps a better solution is to not enforce that policy but instead require long passwords. If you do the math you will see that a nine-character lower-case password is roughly as complex as a seven-character password that uses upper and lower-case letters and numbers. The only difference is how the password cracking software handles different character subsets; some brute-force password crackers may attempt all lower-case letters before trying numbers
Another alternative is to take the Platform SDK sample in the \samples\winbase\Security\WinNT\PwdFilt\ directory and modify it to be a little more forgiving with password selection.
Educating users on what makes a password complex and giving them some ideas for strong passwords will also help.
Myth #10: Use ALT+255 for the Strongest Possible Password
It common to see recommendations to use high-ASCII characters as the ultimate password tip. High-ASCII characters are those that cannot normally be typed on a keyboard but are entered by holding down the ALT key and typing the character's ASCII value on the numeric keypad. For example, the sequence ALT-0255 creates the character <ÿ>.
Although they are useful in some situations, you should also consider the disadvantages. First of all, holding down the ALT key and typing on the numeric keypad is something that can easily be observed by others. Second, creating such a character requires five keystrokes that must be memorized and later typed every time the password is entered. Perhaps a more effective technique would be to make your password five characters longer, which would actually make your password much stronger for the same number of keystrokes.
For example, a five-character password made up of high-ASCII characters will require 25 keystrokes to complete. With 255 possible codes for each character and five characters, the total possible combinations are 255^5 (or 1,078,203,909,375). However, a 25-character password made up of only lower-case letters has 26^25 (or 236,773,830,007,968,000,000,000,000,000,000,000) possible combinations. Clearly, you are better off just making longer passwords.
Another thing to consider is that some laptop keyboards make numeric keypad input difficult and some command-line tools may not accept high-ASCII characters. For example, you can use the character ALT+0127 in Windows, but you cannot type that character at a command prompt. Conversely, I have found that some character codes such Tabs (ALT+0009), LineFeeds (ALT+0010), and ESC (ALT+0027) can be used when setting your password from a command prompt but cannot be used in any Windows dialog boxes (which may actually be a desirable side-effect in some rare cases).
Nevertheless there are times where it is good advice to use extended characters codes. If you have sensitive service or local admin accounts that are rarely used, sometimes the extended character set will be worth the extra keystrokes. Since few password crackers are set up to handle extended characters, that may be enough to make your password very difficult to crack. But in that case, don't stop with high-ASCII, one little-known fact is that you can actually make use of the full Unicode character set which has 65,535 possible characters. Still, a character such as ALT+65206 is not as strong as the equivalent number of keystrokes using regular characters.
One final note on extended characters is the use of the non-breaking space (ALT+0160). This character appears as a space and can often fool those who are somehow able to view the password. Say, for example, that an attacker is able to install a keylogger on your system. If you use a non-breaking space in your password, it will look like a regular space in the keylogger's logfile. But if the attacker is not aware of the non-breaking space, and without seeing the actual ASCII code, the password they think they have will fail. And many people simply are not aware that this character exists, although perhaps they do now.
Conclusion
Some may disagree with individual points I have presented here, but that is the whole purpose. A myth is a half-truth. Many of the myths that I have attacked here were once good advice or they still are good advice but only in specific scenarios. But to many this advice has become a set of solid rules that are generally applied to all scenarios. Password advice, including my own, is nothing more than advice. You must determine which rules work for you and which do not. Perhaps the biggest myth of all is that there are fixed rules when it comes to password security.
Sometimes John99 is a good password and sometimes passwords must be changed in less than 30 days. Some passwords, such as administrator passwords, need more protection while others, such as user passwords, need less. You must take what you know as well as what I presented here to form a password policy that protects you best.
A good password is more than just a complex password. A good password is one that is not easily guessed but still easy to remember. It should be long and should consist of letters, number, and symbols, but still easy to type quickly with few errors. It should have elements of randomness that only a computer can provide while still having familiarity that only a human can provide.
But the best password of all is the one that the user chooses based on an educated understanding of passwords - a password that is hard to crack, but never forgotten. And the best password policy is one that helps users in creating these passwords.
---www.securityfocus.com

How to Write Good Passwords

A good password isn't a password at all. Instead, it's a system for creating codes that are easy to remember but hard to crack.

A good password isn't a password at all. Instead, it's a system for creating codes that are easy to remember but hard to crack. And by codes we do mean codes, plural, so that someone who finds out one of your passwords won't know them all. Here's one methodology to help you generate unguessable but memorable gibberish.

Step 1: Choose a core phrase. Start with a phrase that's at least five words long. It could be the first line of a song, a quotation, a book title - anything that sticks in your head. Draw your core password from that, perhaps by using the first letter of each word:

tcith

These are the first letters of the book title "The Cat in the Hat," for example.

The payoff: This simple step protects you from someone who is running what's called a dictionary attack, in which every single word in the dictionary (and many proper names too) are tried until the right one is found. Computers can run through a dictionary attack in no time flat.

Step 2: Replace some lowercase letters with capital letters, numbers or symbols. Now mix things up by creating conventions around letters that you'll always make uppercase or change to symbols or numbers. Do what makes sense to you, so you don't have to write your system down:

Tc!tH

Here, we've capitalized the first and last letters of the phrase, and replaced an "i" with an exclamation point. You could also make "@" stand in for "a," "1" stand in for "l," and so on.

The payoff: This step exponentially increases the amount of time it takes for someone who is running a password-cracking program that burns through every possible combination of characters until it finds the right one. Rather than guessing from the 26 lowercase letters on the keyboard, the program has to try 52 uppercase and lowercase letters, plus 10 digits and at least 10 more punctuation marks.

Step 3: Customize the password for each site or application. You can use the same core password multiple times, but add a character or three to ensure that every passphrase includes a number, and also that the passphrase is at least seven characters long. To get there, think up a system for generating an extra letter and number based on the name of the website or program you're accessing.

o5Tc!tH

Assuming that the password is for a Yahoo webmail account, we've added an "o" - for the last letter of Yahoo - and a 5, for the number of letters in Yahoo.

The payoff: We started with a password of five lowercase letters, which has 11,881,376 variations (26 to the fifth power, for math wonks). After step three, our password has more than 10 trillion combinations of characters (72 to the seventh power). Even a desktop computer that can guess a million passwords per second will need more than three months to run through all those possibilities.

Step 4: Write down your hint. As long as you understand your methodology and rules, now you can write down a mnemonic device that will jog your memory without being obvious to anyone else. You should still keep this piece of paper hidden, though. Author and security expert Bruce Schneier recommends keeping actual passwords on a piece of paper in your wallet, because you guard it closely and know when it goes missing. Keeping hints there should be even safer. This would be enough to make us remember that we used the title "The Cat in the Hat" to generate our basic password.

Step 5: Repeat. While you can use the same core phrase for multiple accounts, make sure that you establish different levels of passwords. You could use the same core phrase for all accounts that don't involve financial information, another one for accounts where you've used your credit card number and a third for online banking. In an ideal world, passwords should be changed at least every 90 days. But most of us would be doing pretty well if we changed them whenever daylight-saving time starts and stops.

Reference : www.csoonline.com

Vedea: Microsoft Visualization Language coming ...

Microsoft announced of introducing a new visualization language called “Vedea” in early 2010. Vedea is a prototype of a new experimental language for creating interactive infographics, data visualizations and computational art. Its designed to be accessible to people who’re either new to programming or whose primary domain of expertise is something other than programming. We wanted to give those users a tool that they can use to realize their own vision and visualizations without having to engage skilled programmers, but’ve it be an environment that skilled programmers would not find limiting. Veda is built on .net 4.0’s new Dynamic Language Runtime, and gives us some important advantages over more traditional language implementations. Syntactically, Vedea language looks a lot like C#. Microsoft Visualization Language and its runtime will first be available on via Veda site.

Python Tutorial (Operators)

Mathematical operators
+ - * / // % **

// floor division
** exponential operators

Comparison operators, which return a Boolean value indicating the truthfulness of the expression:
< <= > >= == != <>

Python currently supports two "not equal" comparison operators, != and <>.

and or not

We can use these operations to chain together arbitrary expressions and logically combine the Boolean results:
>>> 2 < 4 and 2 == 4
False
>>> 2 > 4 or 2 < 4
True
>>> not 6.2 <= 6
True
>>> 3 < 4 < 5
True
They are simply identifier names with an alphabetic first character "alphabetic" meaning upper-or lowercase letters, including the underscore ( _ ). Any additional characters may be alphanumeric or underscore. Python is case-sensitive, meaning that the identifier "cAsE" is different from "CaSe." Python is dynamically typed, meaning that no pre-declaration of a variable or its type is necessary. The type (and value) are initialized on assignment. Assignments are performed using the equal sign. >>> counter = 0

>>> m = 1000.0
>>> name = 'sameer'
>>> counter = counter + 1
>>> km = 1.609 * m
>>> print '%f miles is the same as %f km' % (m, km)
1000.000000 miles is the same as 1609.000000 km


Python also supports augmented assignment, statements that both refer to and assign values to variables. You can take the following expression ...
n = n * 10

...and use this shortcut instead:
n *= 10

Python does not support increment and decrement operators like the ones in C: n++ or --n. Because + and -- are also unary operators, Python will interpret --n as -(-n) == n, and the same is true for ++n.
Python supports five basic numerical types, three of which are integer types.
· int (signed integers)
o long (long integers)
o bool (Boolean values)
· float (floating point real numbers)
· complex (complex numbers)


Here are some examples:
int 0101 84 -237 0x80 017 -680 -0X92
long 29979062458L -84140l 0xDECADEDEADBEEFBADFEEDDEAL
bool True False
float 3.14159 4.2E-10 -90. 6.022e23 -1.609E-19
complex 6.23+1.5j -1.23-875J 0+1j 9.80665-8.31441J -.0224+0j

There is also a sixth numeric type, decimal, for decimal floating numbers, but it is not a built-in type. You must import the decimal module to use these types of numbers. They were added to Python (version 2.4) because of a need for more accuracy. For example, the number 1.1 cannot be accurately representing with binary floating point numbers (floats) because it has a repeating fraction in binary. Because of this, numbers like 1.1 look like this as a float:
>>> 1.1
1.1000000000000001
>>> print decimal.Decimal('1.1')
1.1

Delimiters
The following tokens serve as delimiters in the grammar:

( ) [ ] { } @
, : . ` = ;
+= -= *= /= //= %=
&= |= ^= >>= <<= **=

The period can also occur in floating-point and imaginary literals. A sequence of three periods has a special meaning as an ellipsis in slices. The second half of the list, the augmented assignment operators, serve lexically as delimiters, but also perform an operation.

The following printing ASCII characters have special meaning as part of other tokens or are otherwise significant to the lexical analyzer:

' " # \

The following printing ASCII characters are not used in Python. Their occurrence outside string literals and comments is an unconditional error:

$ ?

FreeBSD 8.0 relesed.

• A new virtualization container named “vimage” has been implemented. This is a jail with a virtualized instance of the FreeBSD network stack and can be created by using jail(8) command.

• The FreeBSD netisr framework has been reimplemented for parallel threading support. This is a kernel network dispatch interface which allows device drivers (and other packet sources) to direct packets to protocols for directly dispatched or deferred processing. The new implementation supports up to one netisr thread per CPU, and several benchmarks on SMP machines show substantial performance improvement over the previous version.

• The FreeBSD TTY layer has been replaced with a new one which has better support for SMP and robust resource handling. A tty now has own mutex and it is expected to improve scalability when compared to the old implementation based on the Giant lock.

• [amd64, i386] The FreeBSD Linux emulation layer has been updated to version 2.6.16 and the default Linux infrastructure port is now emulators/linux_base-f10 (Fedora 10).

• The FreeBSD GENERIC kernel now includes Trusted BSD MAC (Mandatory Access Control) support. No MAC policy module is loaded by default.

• The FreeBSD USB subsystem has been reimplemented to support modern devices and better SMP scalability. The new implementation includes Giant-lock-free device drivers, a Linux compatibility layer, usbconfig(8) utility, full support for split transaction and isochronous transaction, and so on.

• The FreeBSD CAM SCSI subsystem ( cam(4)) now includes experimental support for ATA/SATA/AHCI-compliant devices.

• The shared vnode locking for pathname lookups in the VFS(9) subsystem has been improved.

• The ZFS file system has been updated to version 13. The changes include ZFS operations by a regular user, L2ARC, ZFS Intent Log on separated disks (slog), sparse volumes, and so on.

• The FreeBSD NFS subsystem now supports RPCSEC_GSS authentication on both the client and server.

• The FreeBSD NFS subsystem now includes a new, experimental implementation with support for NFSv2, NFSv3, and NFSv4.

• The wireless network support layer (net80211) now supports multiple BSS instances on the supported network devices.

• The FreeBSD L2 address translation table has been reimplemented to reduce lock contention on parallel processing and simplify the routing logic.

• The IGMPv3 and SSM (Source-Specific Multicast) including IPv6 SSM and MLDv2 have been added.

• The ipsec(4) subsystem now supports NAT-Traversal (RFC 3948).

• The GCC stack protection (also known as ProPolice) has been enabled in the FreeBSD base system.

• The supported version of the GNOME desktop environment (x11/gnome2) has been updated to 2.26.3.

• The supported version of the KDE desktop environment (x11/kde4) has been updated to 4.3.1.

For more details, please see the Detailed Release Notes.

Python Tutorials.

Work on Python began in late 1989 by Guido van Rossum, then at CWI (Centrum voor Wiskunde en Informatica, the National Research Institute for Mathematics and Computer Science) in the Netherlands. It was eventually released for public distribution in early 1991.
At the time, van Rossum was a researcher with considerable language design experience with the interpreted language ABC, also developed at CWI, but he was unsatisfied with its ability to be developed into something more. Having used and partially developed a higher-level language like ABC, falling back to C was not an attractive possibility. Some of the tools he envisioned were for performing general system administration tasks, so he also wanted access to the power of system calls that were available through the Amoeba distributed operating system. Although van Rossum gave some thought to an Amoeba-specific language, a generalized language made more sense, and late in 1989, the seeds of Python were sown.

Python buzzword –
High level
Object oriented
Scalable
Extensible
Portable
Easy to learn
Easy to read
Easy to maintain
Robust
Effective as rapid prototype tool
A memory Manger
Interpreted and (byte) compiled

Command-Line Options
When starting Python from the command-line, additional options may be provided to the interpreter. Here are some of the options to choose from:

-d Provide debug output
-O Generate optimized bytecode (resulting in .pyo files)
-S Do not run importsite to look for Python paths on startup
-v Verbose output (detailed trace on import statements)
-m mod run (library) module as a script
-Q opt division options (see documentation)
-c cmd Run Python script sent in as cmd string
file Run Python script from given file (see later)

>>>(primary prompt)
……(secondary prompt)
Other Implementation

1.Cpython
2.jpython
3.IronPython
4.Stackless


Functions that do not explicitly return a value by the programmer automatically return None, Python's equivalent to NULL


You will notice two primary ways that Python "does things" for you: statements and expressions (functions, equations, etc.). Most of you already know the difference between the two, but in case you need to review, a statement is a body of control which involves using keywords. It is similar to issuing a command to the interpreter. You ask Python to do something for you, and it will do it. Statements may or may not lead to a result or output. Let us use the print statement for the programmer's perennial first example, Hello World:
>>> print 'Hello World!'
Hello World!
Expressions, on the other hand, do not use keywords. They can be simple equations that you use with mathematical operators, or can be functions which are called with parentheses. They may or may not take input, and they may or may not return a (meaningful) value. (Functions that do not explicitly return a value by the programmer automatically return None, Python's equivalent to NULL.) An example of a function that takes input and has a return value is the abs() function, which takes a number and returns its absolute value is:
>>> abs(4)
4
>>> abs(-4)
4

The underscore (_) also has special meaning in the interactive interpreter: the last evaluated expression. So after the code above has executed, _ will contain the string:
>>> _
Hello World!

Python's print statement, paired with the string format operator ( % ), supports string substitution, much like the printf() function in C:
>>> print "%s is number %d!" % ("Python", 1)
Python is number 1!

The print statement also allows its output directed to a file. This feature was added way back in Python 2.0. The >> symbols are used to redirect the output, as in this example with standard error:
The print statement also allows its output directed to a file. This feature was added way back in Python 2.0. The >> symbols are used to redirect the output, as in this example with standard error:

import sys
print >> sys.stderr, 'Fatal error: invalid input!'

Here is the same example with a logfile:
logfile = open('/tmp/mylog.txt', 'a')
print >> logfile, 'Fatal error: invalid input!'
logfile.close()

Program Input and the raw_input()Built-in Function

The easiest way to obtain user input from the command line is with the raw_input() built-in function. It reads from standard input and assigns the string value to the variable you designate. You can use the int() built-in function to convert any numeric input string to an integer representation.
>>> user = raw_input('Enter login name: ')
Enter login name: root
>>> print 'Your login is:', user
Your login is: root

Comments
As with most scripting and Unix-shell languages, the hash or pound ( # ) sign signals that a comment begins from the # and continues until the end of the line.
>>> # one comment
... print 'Hello World!' # another comment
Hello World!

There are special comments called documentation strings, or "doc strings" for short. You can add a "comment" at the beginning of a module, class, or function string that serves as a doc string, a feature familiar to Java programmers:
def foo():
"This is a doc string."
return True

Unlike regular comments, however, doc strings can be accessed at runtime and be used to automatically generate documentation.