Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
these char can be entered by keyboard by pressing with the combination of ALT and ASCII of char
I think these ☺ ☻ ♥ ♦ ♣ char can't be easily cracked by brute force attack.
It would depend a bunch of things, including what program is accepting the password, where and how are they storing it, what platforms the server and client are running on, and likely others. You may be able to log in using this password from a Windows client but not Unix (or vice versa). If this is a web app, it might work on one browser but not another. Or it might work differently on an English machine vs. a Japanese machine.
I would recommend against this. It's easy enough to come up with secure 7-bit ASCII passwords that going down this road isn't really necessary.
If the question is "can I use these," then the answer is "maybe." You will need to test them thoroughly to make sure that your application(s) support extended ASCII characters in passwords. If you use various operating systems or mixed-language systems, it's somewhat less likely that they'll be compatible because you start getting into different issues with encodings. There are many versions of the so-called extended ASCII set and they can be represented very differently.
If the question is "are these more secure," then the answer is "not really." Sure, increasing the number of characters that can potentially be included in a password increases its entropy value and increases the amount of time it would take for password-cracking software to crack the password. However, in practice, it's relatively unlikely that you'll see much difference by adding 5 or 6 extra characters. You can get a sufficient level of security with the password complexity requirements that are already well-supported, and tactics like increasing the minimum length of your password (perhaps to something like a pass phrase, rather than a simple word) will make cracking much more difficult than a few additional characters.
Also see the documentation for passwords in Windows Server:
An example of a strong password is
J*p2leO4>F.
A password can meet most of the
criteria of a strong password but
still be rather weak. For example,
Hello2U! is a relatively weak password
even though it meets most of the
criteria for a strong password and
also meets the complexity requirements
of password policy. H!elZl2o is a
strong password because the dictionary
word is interspersed with symbols,
numbers, and other letters. It is
important to educate users about the
benefits of using strong passwords and
to teach them how to create passwords
that are actually strong.
You can create passwords that contain
characters from the extended ASCII
character set. Using extended ASCII
characters increases the number of
characters that you can choose when
you create a password. As a result, it
might take more time for
password-cracking software to crack
passwords that contain these extended
ASCII characters than it does to crack
other passwords. Before using extended
ASCII characters in your password,
test them thoroughly to make sure that
passwords containing extended ASCII
characters are compatible with the
applications that your organization
uses. Be especially cautious about
using extended ASCII characters in
passwords if your organization uses
several different operating systems.
You can find extended ASCII characters
in Character Map. Some extended ASCII
characters should not be used in
passwords. Do not use a character if a
keystroke is not defined for it in the
lower-right corner of the Character
Map dialog box. For more information
about how to use Character Map, see
Using Character Map.
Examples of passwords that contain
characters from the extended ASCII
character set are kUµ!¶0o and
Wf©$0k#»g¤5ªrd.
OK, not even close to a programming question, but I'll answer it anyway.
The policy for what is and is not allowable in a password is decided by the individual application/website etc.
So long as the characters are valid input for a password, they can be brute-forced just as easily as any other character. A short password with strange characters is still many times weaker than a longer password made from alphanumeric characters.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I am trying to penetration test one of my websites.Username and Password is unknown to me.I am trying to break username and password using brute force attack.
Although,This strategy should be straight as I need to keep generating a new alphanumeric combination of variable length each time and posting it using some self written program.
But this strategy needs a lots of processing time and power. My Simple doubt is that is this strategy good enough for username and password breaking or some other task is expected to be done.
I have heard a lot about dictionary attack,But that too requires a predefined and pre-expected lists of usernames and passwords.
Should I go for brutus(but it didn't worked for me) or a self written program?
What is the right way of enlisting the username and passwords?
Online brute-force attacks against a live system are not viable as it’s simply too slow: limited bandwidth, latency, throttling, perhaps Captchas, etc. One could try a dictionary attack, but probably only with a very short list of passwords.
But for offline password attacks, where the attacker is in possession of the password hash, the only limiting factor is the hardware and software of his own system. However, often brute-force attacks are still viable only against high-value targets due to cost-benefit ratio.
Not only is it achievable, with modern approaches using GPUs and FPGAs, it's an incredibly viable approach. Note this doesn't necessarily apply to client-server models. However, if you have encrypted data protected by something such as PBKDF2, it is possible with enough computing power that the password and therefore key could be recovered. The appropriate approach depends on what it is you're trying to attack. Attacking websites is much more difficult as without a distributed attack the site can simple throttle its responses, slowing your attack time.
When going through registration, a lot of sites will disallow the use of symbols in passwords. This drives me up the wall from a usability perspective since I include multiple symbols in all my passwords, and as a programmer that deals with web authentication from time to time, I can't figure out why it wouldn't be allowed. Am I missing something? Are they worried about SQL injection? Don't want to deal with escaping characters? Or is there something with non-Latin-alphabet characters that can mess things up?
Similar question, about sites that restrict length here.
Laziness, 2. Using legacy systems that don't support those characters for auth
They are morons
They are almost certainly storing the plain text password somehwere (see 1)
They aren't in the US: In Europe, you have a different keyboard every few miles. Good luck finding your special character on an Italian keyboard. Or a Greek one. Or Turkish.
The only keys which are probably there are the alphanumeric keys and most people will be able to find their way around them, even if a couple of the keys will be swapped (Y and Z, for example).
Lastly, people are notoriously bad at remembering passwords. Forcing them to use "honey" instead of "jh(/&DFA93475" greatly reduces the rate of calls for support ("I can't remember my password...")
If it's a web app, the developers were not really able to make sure that umlauts survive the transfer from the form to their backend. It would be great if all browser would simply send UTF-8 but most backends can't handle UTF-8 without some careful tuning, either.
It probably means they're lazy or not very smart. If you only store a hash, you won't have to worry about character sets, injections, or space. Pretty much what was explained in that other question you gave.
Our system once had to work together with 3rd party hardware which was operated through touchscreen. Their on-screen errr.... 'keyboard', surely didn't had a non-alphanumeric characters, therefore - we ran into quite serious trouble with passwords - clients had to change them.
Legacy Systems Support
I can't say if it is true for many websites, but in many antiquated network environments that use radius or another form of centralized authentication, often you have to restrict your passwords to the lowest common denominator for all of the disparate systems that you are supporting. So if you are supporting password authentication for a poorly written legacy application that has problems with non-ascii characters and that server piggy backs onto the central authentication server, you are forced to limit all of the other servers to the same password restrictions.
Poor Input Validation and Lack of Password Hashing / Encryption
The applications could have had SQL injection issues in the past and over-zealous programmers just disabled all not ascii rather than address the fundamental flaws in their design.
Unneeded Simplification
The developers may want to minimize issues with binary data petering into the password store and are over-zealous in their data validation. Honestly, I think this is the most likely scenario. The programmers may have already taken an ascii-only approach to usernames and just extended the same line of thinking to passwords.
Bad programming, and the fact they're storing it in clear text, I'm sure.
One possible reason: the site's UI is designed by a marketing type or a non-technical product manager. Someone who doesn't understand combinatorics and thinks they actually provide their developers with precise requirements by dictating that the password field must contain exactly 8 alphanumeric characters.
It's possible that the same password will need to be entered via the phone keypad, (1 = 1, A, B, or C).
Realizing that this is terribly insecure, one way of increasing the security would be to lock the account after X bad password attempts. Often bank websites are just a front end for a horribly old mainframe application and can't change password policies.
The reason they require alphanumeric is usually an attempt to prevent SQL injection when passwords are entered. For example:
On some sites you can actually type in:
U: admin
P: ' or 't' = 't
Normally programmers get through this by using programming practices such as parameterized SQL, but I am willing to bet this is why they are doing it.
it's a toe crunching, teeth grinding issue especially when banks do it; however, I think some of the issues are with the ';' and ' ' " ' characters.
Back in the day some programmers, i suspect, thought by forcing alphanumeric characters, that people might forget their passwords easily.
Years ago it used to be the case that Unix passwords were limited to 8 characters, or that if you made the password longer than 8 characters the extra wouldn't make any difference.
Is that still the case on most modern Unix/Linux systems?
If so, around when did longer passwords become possible on most systems?
Is there an easy way to tell if a given system supports longer passwords and if so, what the effective maximum (if any) would be?
I've done some web searching on this topic and couldn't really find anything definitive; much of what came up was from the early 2000s when I think the 8 character limit was still common (or common enough to warrant sticking to that limit).
Although the original DES-based algorithm only used the first 8 characters of the password, Linux, Solaris, and other newer systems now additionally support other password hash algorithms such as MD5 which do not have this limit. Sometimes it is necessary to continue using the old algorithm if your network contains older systems and if NIS is used. You can tell that the old DES-based algorithm is still being used if the system will log you in when you enter only the first 8 characters of your >8-character password.
Because it is a hash algorithm, MD5 does not have an intrinsic limit. However various interfaces do generally impose some limit of at least 72 characters.
Although originally the encrypted password was stored in a world-readable file (/etc/passwd), it is now usually stored in a separate shadow database (e.g. /etc/shadow) which is only readable by root. Therefore, the strength of the algorithm is no longer as important as it once was. However if MD5 is inadequate, Blowfish or SHA can be used instead on some systems. And Solaris supports pluggable password encryption modules, allowing you to use any crazy scheme. Of course if you are using LDAP or some other shared user database then you will need to select an algorithm that is supported on all of your systems.
In glibc2 (any modern Linux distribution) the password encryption function can use MD5/SHA-xxx (provoked by a magic salt prefix) which then treats as significant all the input characters (see man 3 crypt). For a simple test on your system, you could try something like:
#!/bin/perl -w
my $oldsalt = '##';
my $md5salt = '$1$##$';
print crypt("12345678", $oldsalt) . "\n";
print crypt("123456789", $oldsalt) . "\n";
print crypt("12345678", $md5salt) . "\n";
print crypt("12345678extend-this-as-long-as-you-like-0", $md5salt) . "\n";
print crypt("12345678extend-this-as-long-as-you-like-1", $md5salt) . "\n";
(which on my system gives)
##nDzfhV1wWVg
##nDzfhV1wWVg
$1$##$PrkF53HP.ZP4NXNyBr/kF.
$1$##$4fnlt5pOxTblqQm3M1HK10
$1$##$D3J3hluAY8pf2.AssyXzn0
Other *ix variants support similar - e.g. crypt(3) since at least Solaris 10.
However, it's a non-standard extension - POSIX does not define it.
Not for Linux. It's only 8 if you disable MD5 Hashing.
http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/security-guide/s1-wstation-pass.html
You can administer policies enforcing longer and more complex passwords as well.
The full lengths are discussed here:
http://www.ratliff.net/blog/2007/09/20/password-length/
Are you asking about the crypt algorithm?
http://linux.die.net/man/3/crypt
"By taking the lowest 7 bits of each of the first eight characters of the key..."
"The glibc2 version of this function has the following additional features. ... The entire key is significant here (instead of only the first 8 bytes)."
Here's a hint as to how long ago this change happened.
Glibc 2 HOWTO
Eric Green, ejg3#cornell.edu
v1.6, 22 June 1998
You will find this article of interest. There is something called PAM (Password Authentication Module) which runs your password through a series of modules (configured in /etc/pam.d/passwd or /etc/pam.conf) to determine whether the password is valid or not.
I think around the time when actual passwords were moved from /etc/passwd to shadow, on Linux . I am guessing around 2000, Red Hat 6.x had long passwords IIRC. Around 2000 there were still a lot of old SUN, and they had password and username limits.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Pros:
I can't remember "good" passwords anyway so remembering them is not an issue.
they don't look like passwords
they are darn near impossible to guess (128 bits of entropy)
easy to generate (offloads the "good PRNG" problem)
Cons:
???
In particular; what about for passwords that computers enter like for databases logins on some setups.
One major con is that you don't necessarily have "128 bits of entropy" as stated in the original question.
Many GUID Algorithms have information embedded in them in predictable patterns, for example the MAC address of the computer, the date/time, or an incrementing sequence. Cryptanalysis of the WinAPI GUID has shown given the initial state one can predict up to next 250,000 GUIDs returned by the function UuidCreate
For example, I have about a 50% chance of guessing the first digit in the first position of the third group of digits since it will be either 1 (for V1 guids) or 4 (for V4 guids)
Source: http://en.wikipedia.org/wiki/Globally_Unique_Identifier
Cons:
You will write them down somewhere.
You will probably email them, or write them down again if you need to tell anyone else.
They may be too long for certain systems.
They're practically impossible to memorize, so you might change them more frequently then desired.
So unless they're system passwords which change rarely, I doubt they are good passwords.
Con:
It would be nearly impossible to remember a 32-byte alpha numeric string.
If you really want a secure password, consider a passphrase instead. A long passphrase is easily remembered, and very difficult to brute force.
Con:
Some systems have limits on the maximum length of passwords. If you're only using hex digits this can limit your entropy to perhaps as little as 32 bits.
Cons:
Password fields are not always long enough.
More difficult to enter - you'd probably store the password in a program, not in your head. That's a bit of a security problem...
... pros:
Nobody will be able to force your password out of you.
Big-random-number passwords have been done before. They're called OTPs, and are much more secure than what you're suggesting because they change over time, and tend to be generated by secure devices. Of course this is only relevant if you are designing a password system.
Does anyone ever need to enter it as a password? Or do you want to use it as a one-time thing? Because seriously, no one wants to enter a GUID in a passwordfield. People have trouble enough as it is, entering WEP/WPA2 wifi network keys. And most of the time, those are one-timers.
#Miyagi: that's the most obvious con ofcourse. They'll have to write it down.
Technically they would be good passwords
In real life, they would be horrible passwords
You would end up having to write down the passwords, use a password manager, or some other form to actually use the password... in a way moving the failure point from the password to another aspect.
Consider using passphrases. Sentences with substitutions for certain letters or other characters, and for numbers, typing them with the SHIFT, converting easy to remember numbers in to well defined character sequences.
For example bcs19850101bcs would be bcs!(*%)!)!bcs
If you want a secure password that you wish to leave to a password manager on a UNIX-like system, you're much better just pulling one from /dev/random and encoding it into something readable. for 128 bits of entropy you can use something simple like
head -c 16 /dev/random | openssl enc -a -e
which gives a password like 5eqIviKu4pFTqSPnYosVKg==
not unreasonably long, secure, random, suicide to try to remember.
Edit: added benefits of this method over UUID include extra security in the PRNG (/dev/random) and shorter passwords, similar shortfalls
I recently wrote code to convert the first 64 bits of a checksum into a sequence of four English words. This makes a good checksum (much easier to remember than a hex mess), but I'm not sure I'd trust it as a password. If you're protecting something secure, you should use a strong password that you memorize and don't write down. If not, then any old password will do.
I think what you actually want is a cryptographically-random number, not a GUID. GUIDs and UUIDs are not random -- as JohnFx said, they tend to incorporate discoverable values like the MAC address or current timestamp, in order to guarantee uniqueness.
Instead, you should look at whatever crypto API is available to you and find a source of high-entropy random numbers. Make sure the documentation promises the output is suitable for cryptography, not just a regular PRNG. For example, /dev/random on Unix systems is a good source. Then just unroll as many random bytes as you want.
Personally this seems a bit too hardcore. I'd rather generate strings that contain a bit less entropy per character, but are easier to type and remember. For example, there are several algorithms that combine random syllables to create pronounceable nonsense words; intersperse some digits and punctuation, and you've got a good password.
I like my passwords strong and pronouncable (try one of the sites listed here for an online demo, be sure to pick a "v2" site to get the pronounciation-guide).
Con: You can't retype it, which means you will have to copy and paste. If you have your password management program on your system, not really a problem. But if you end up on a system where you don't, just retyping the thing will be very difficult.
And then after you try a couple of times you get locked out ....
Life could get very annoying.
Even if you write it down, a good password is something you can type consistently without errors.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Bonus points for explaining how you improved it.
Real life security by obscurity?
The key to the front door is stashed under a rock nearby, or under the welcome mat, or on top of a high railing.
These are all instances of security through obscurity, as in, it is right out in the open for anyone to grab, but most people wont be able to find it without huge amounts of searching. However, a dedicated attacker can walk right in.
Some people like to make their javascript difficult to read (and therefore hack) by using obfuscation. Google is among the users of this technique. At the simplest level, they change the variable and method names to a single inscrutable letter. The first variable is named "a", the second is named "b" and so on. It does succeed in making the javascript exceedingly difficult to read and follow. And it adds some protection to the intellectual property contained in the javascript code, which must be downloaded to the user's browser to be usable, therfore making it accessible to all.
In addition to making it difficult to read the code, this shortening of variable names reduces the size of the javascript code that has to be downloaded to the user's browser. Theoretically, this can reduce network traffic.
Here's an article about Google's obfuscation, and here's a list of available tools.
On a website I did some contract work on I noticed that they were storing double-hashed passwords. From memory, they were storing something like
$encrypted_password = md5( sha1( plaintext_password ) );
When I asked what the purpose of this was, I found out that the guy who wrote the account creation/login script had been reading about dictionary attacks. He figured that no one would ever think to create a dictionary where they hash inputs with md5 and sha1.
I improved the system by adding a random salt column to their user table. I left the double-hashing in though. It doesn't do anything to hurt the security of the system, and to be honest, I thought it was pretty clever for someone who didn't really know much about security to think of this.
Seen: Websites use a complex url to access ajax components rather than actually password protect them such as:
domain.com/3r809d8f09feefhjkdjfhjdf/delete.php?a=03809803983djfhkjsdfsadf
the string has remained constant, the query is random and is designed to stop attackers.
Improvement: Restrict the page to being accessed only from certain IP addresses. Add an authentication string to the query that is a salted hash of the access time.
In a more "real life" example, I don't know if it's intentional or not, but I like the way none of the doorbells in my block have any names on them, and that their numbers seem to have no correlation to the apartement numbers whatsoever. Ie. ring on #25 for apartement 605, #13 for apartement 404 and so on. :)
One vendor we deal with requires us to post the username and password in the querystring in ROT-13 "encrypted" format. No joke.
Security through obscurity is a valid tactic. Plenty of people have turned off replying with version information as a best practice for ftp and apache. Honeypots can be considered an obscured practice, since the attacker doesn't know the layout of the network and gets sucked into them. One high security site I know of assigns their username by a five digit alphanumeric phrase (such as '0a3bg') instead of using logical usernames. Anything that makes breaking into a system more difficult, or take longer, is a valid measure.
Security exclusively through obscurity is bad.
People writing their password on pieces of paper and putting it under their keyboard.
I solved it by logging into their computer with their account and sending out an embarrassing email to the group.
Seen: phpMyAdmin moved into the directory _phpmyadmin
Improvement: Disallowed access from outside the company's network.
Similar to #stech's solution.
Some of the admin pages in our application on the web, check for a local IP subnet range, else display access denied.
Improvement is accessed is restricted to users who are inside the network or VPNed to it.
Back in the old DBase/Clipper days I worked for a guy who developed an application for a friend of his. This friend wanted to have some "secretly" accessible program or data (I don't recall) that required a password only known to him.
The solution, I was told, was that Clipper opened a DOS prompt in the secret directory, with black text on black background colors (some ANSI control characters accomplished this).
The user had to type in the password, but this being input line of the DOS command prompt, the "password" was really the name of a batch file that was then executed.
I once saw a photography website where you could strip some characters off from the photo thumbnail pictures url to get the full version.
Many professional photographer websites use Javascript to prevent people from right-clicking on images to "save as ...". Most of those sites also don't do any watermarking.
I used to surf with referer headers disabled... it's quite surprising how many websites will blow up or flat-out reject you if they don't know where you came from.
One website had a poll and used cookies to prevent you from voting multiple times. You could simply erase that cookie and keep voting. And you could script it all using wget, too.
The example I see of this all the time is something being done in source code that the developer assumes no one will ever see. You see this a lot with crypto-keys in particular, embedded right in the source code. A lot of times it is not even a question of decompiling the code, they could outright just use the library.
The solution is always to teach the developer to assume that someone has the source code and can use it against you.
Going to great lengths to hide software names and version numbers .
Ie. changing Tomcat server name and version to some quotes and random numbers (like 666), changing the name and version numbers of regular javascript libraries like scriptaculous and prototype and so on.
In a current project we're using Google Web toolkit (GWT) and this sneaky little thing compiles Java to javascript (which you have little to no control over) and includes the string "GWT" and version number. Totally unacceptable of course so we'll need to make a script that will run after GWT compile to remove all these references(!).
/admin without password.
Yes I've seen it, it's very real.