Jump to content

Talk:Password cracking/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

McBurz thingo?

This doesn't seem relevant or neccessary. The link leads to non-free software even, and below, it says that a list would be better suited to dmoz. facebook haking — Preceding unsigned comment added by 203.190.9.74 (talk) 15:43, 21 April 2018 (UTC)

Ok Abdullahi90675 (talk) 11:32, 10 September 2021 (UTC)

A note on salts and Unix passwords

A recent edit, which I reversed, mentioned that longer salts are trivial. This is often not true. When a hash function is used for password hashing/encryption, it is trivial to append or prepend the salt. The salt can even be used in the computation multiple times, as it is in md5-crypt, when the password, salt, and/or intermediate hash values are rehashed as part of a password stretching scheme.

In other algorithms, this is not as simple. In DES-crypt, the salt is used to modify the DES expansion function "E". In bcrypt, the salt is used to modify the key schedule. In either of these, a larger salt could require algorithmic changes (depending on how much larger it is) and, beyond some point, may not add any protection. In bcrypt at least, a larger salt could require a non-trivial amount of additional computation. Unicityd (talk) 21:11, 16 October 2008 (UTC)

suggestion for the Prevention section

There are alternatives to what Linux does ;-) http://cvs.openbsd.org/papers/bcrypt-paper.ps

This is already mentioned; bcrypt, the blowfish-based algorithm used in OpenBSD is used in Linux also. It's mentioned under prevention and one of the earlier sections. Unicityd (talk) 05:31, 7 September 2008 (UTC)

incautios editing

Please be slightly more careful while editing. 'Memoization' is a real word, not a typo. It is explained only a couple of sentences before the place where you corrected it to 'memorization'. Also, there are two separate attacks that salting protects against -- precomputation and memoization. Each one can be carried out without the other. Please do not roll them into one or brush one under the carpet. Thank you. Arvindn 02:09, 23 July 2005 (UTC)

Quite right, sorry. --agr 09:17, 24 July 2005 (UTC)

proprietary problem phrase

The statement "Proprietary encryption algorithms which rely on obscurity for security are much more likely to succumb to such attacks." was POV. I think a cited source is in order for this statement.

Agreed. — Matt Crypto 18:48, 23 Mar 2005 (UTC)


Password recovery programs

This page would benefit from an expanded list of password recovery software, including which is freeware and which is not. There are many commercial programs, but I know there are free ones too. I'm thinking of the types of programs which recover passwords from Access, Excel, Word, WordPerfect, and .zip files. There are legit uses for such software, such as finding the password I put on a .zip file I made 5 years ago! 2006-08-18.

Wikipedia is not a directory and should not promote every random software that exists. Those things can be found on directories like dmoz. --Spoon! 10:30, 31 August 2006 (UTC)

GPGPU Password recovery. With newer password recovery software now using GPU power to assist in calculating password hash values, Should this be entered as a sub-section? Also min password length is now recommended as 12 chars or more....Anyone with more info / working knowledge please add in here.... —Preceding unsigned comment added by 92.237.222.215 (talk) 21:21, 6 February 2009 (UTC)

POV

Just in my opinion, some of the section aren't written neutrally. Please remove if you don't see a problem, or fix. RegaL the Proofreader (talk) 18:21, 10 January 2008 (UTC)

What is not neutral? If there are changes that need to be made in this respect, let's make them. Otherwise, I'd like to take off the neutrality dispute tag.--Unicityd (talk) 18:08, 27 August 2008 (UTC)

I tend to agree with Unicityd, although it's surprising to see that the broadly held opinion that proprietary encryption algorithms are a bad idea hasn't been substantiated yet. I will see what I can get up with tomorrow. Sportfanaat (talk) 13:39, 6 September 2008 (UTC)

May I retract that? The word "proprietary" (or was it "proprietory"?) is no longer in the article, so now I am fully in favour of dropping the neutrality dispute tag. Sportfanaat (talk) 13:50, 6 September 2008 (UTC)

Requested move

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the proposal was no consensus to move this page, per the discussion below. Dekimasuよ! 10:34, 23 February 2008 (UTC)

I suppose renaming this article to Password recovery would be more of NPOV. Dadudadu (talk) 23:11, 17 February 2008 (UTC)

Oppose. Password recovery is a subset of password cracking, in that there's the implication that recovery is being done on behalf of someone who in some way owns the information and has a right to recover it. Cracking can mean recovery, but it can also mean breaking someone else's security. This article deals with the general issue of getting access to password protected information without knowing the password, and password cracking is the correct term for this. Andrewa (talk) 09:23, 18 February 2008 (UTC)

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Shouldn't it be Cain and Able?

At the bottom of the page, under see also or Ex. Ref, I saw Cain. If I'm not mistake, shouldn't it be Cain and Able? ~The Unwanted Comment
A Dirge for her, the doubly dead. In that, she died so young. 23:34, 26 March 2008 (UTC) The following statement mix preference with analysis, and I suggest an insertion for the difference between vertical & horizontal password guessing:

POV phrasing claim

"This method is unlikely to be practical unless the password is relatively small. ... in which case the attack is called an offline attack (it can be done without connection to the protected resource), or not, in which case it is called an online attack. Offline attack is generally a lot easier, because testing a password is reduced to a quickly calculated mathematical computation; i.e., calculating the hash of the password to be tried and comparing it to the hash of the real password. In an online attack the attacker has to actually try to authenticate himself with all the possible passwords, where arbitrary rules and delays can be imposed by the system and the attempts can be logged. "

These statements come from assumptions which should not be presumed - i.e. What type of system are you attempting an "online" or "offline" attack against as well as a perceived "preference" of the author towards discouraging online brute force attacks. When discussing methodology of brute force password guessing, standard vertical (many user-single password, horizontal (single user-many passwords) techniquies for "online" password guessing can be quite successful depending on the type of access you are attempting to achieve. RDC, emails, website and vpn all have different levels which may not be covered under the scope of this article, but that does not mean that the method is unlikely to be practical. I don't think the goal here is to explain why there is a preference of which type of attack is more successful depending on what you are trying to access, only the difference between the two. It is conceivable to gain administrator access through RDC in a day. In a horizontal attack against an email address, I have documented lab cases where I can report the users password within 2 hours from a single "attacking" computer. There is a preference stated where "arbitrary rules" and "delays can be imposed by the system", this seems to slant to the author's preference here, there can be "delays" and "rules" which prevent access to hash. Suggest either limiting discussion to what types of attacks and pro's vs. con's objectively. Overall, nice article. - FA of Astral 4/30/08

—Preceding unsigned comment added by 69.118.250.123 (talk) 06:38, 30 April 2008 (UTC)

Weak encryption

This section should be rewriten. A stark encryption method doesn't mean that it is a stark hash method. (it is a common error)

Also, is this sentence correct? "Hash functions like SHA-512, SHA-1, and MD5 are considered impossible to invert when used correctly." based on the content for the MD5 article it would seem an inversion could be possible. —Preceding unsigned comment added by 192.91.173.36 (talk) 15:53, 14 July 2008 (UTC)

I rewrote this section a little bit. The security of the underlying hash function is only the weakpoint when a password scheme is poorly designed; if the hashes are reversible, the scheme is catastrophically bad. The bigger problem even when hashes such as SHA and RIPEMD are used, is that salts are not used and/or the hash is used by itself, not as part of a larger construction, and the attacker can make hundreds of thousands of guesses per second (or more) on a single computer. OpenBSD's bcrypt and FreeBSD's md5-crypt (also on Linux) are much slower and thus harder to crack.Unicityd (talk) 03:59, 15 August 2008 (UTC)unicityd.
The weakness in MD5 makes is possible to create collisions, two inputs that have the same MD5 hash. That is not a concern when using MD5 for password hashes. In particular, it does not make MD5 reversible. The password attack described in the MD5 article refers to rainbow tables, which can be use with any hash, no matter how secure. It is a form of pre-computation that minimizes the amount of storage needed. Salt is the cure as it is for all pre-computation attacks. I also separated human guessable passwords from dictionary attack.--agr (talk) 09:10, 15 August 2008 (UTC)

Possible ammendment to Prevention section

I would suggest ammending the prevention section with the following text ( this includes text from other contributor and some rewording of it.) Original text is

"Solutions like a security token give a formal proof answer by constantly shifting password. Those solutions abruptly reduce the timeframe for brute forcing (attacker needs to break and use the password within a single shift) and they reduce the value of the stolen passwords because of its short time validity. "

My modification and amendment suggestion would be

" Solutions like a security token give a formal proof answer by constantly shifting passwords, also known as one time passwords or OTP. Traditionally these passwords are valid for one use only, for one authenticated session/instance and become invalid when the authenticated session/instance is ended or in some cases when a new one time password is generated/entered.

OTP's are in use in both synchronous or asynchronous security tokens.

OTP's abruptly reduce the timeframe for passwords that are acquired by unauthorised persons to be useful, as these password lose their validity quicker than static passwords. Making a OTP's length and complexity sufficiently strong , while keeping the timeframe for which these OTP's remain valid sufficiently short, coupled with a good creation algorithm can present a significant hurdle for possible attackers to take advantage of. " Djmsec (talk) 13:32, 13 January 2011 (UTC)

Encryption vs Hash

The author of the Prevention category notoriously mixes up encryption with hashing. They are inherently different. Can someone come up with a better way to describe this, or should I rather replace encryption with hashing (considering that the majority of private Unix systems uses SHA/MD5 (because on most distributions those are set by default and almost nobody really changes that) rather than ciphers like Blowfish. 79.242.219.89 (talk) 18:24, 29 January 2011 (UTC)

TRF2040QPC Lusaphandwa (talk) 12:30, 22 November 2020 (UTC)

ADMINS PLEASE NOTE: Article was Being Used to Sell Password Cracking Software

There was a section hawking password-cracking software. Removed.

173.246.35.186 (talk) 13:45, 19 March 2011 (UTC)

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Password cracking. Please take a moment to review my edit. You may add {{cbignore}} after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether, but should be used as a last resort. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 12:45, 31 March 2016 (UTC)

2,800,000,000 passwords a second

I notice that from the link provided, it didn't say there it can crack password with that speed, or did I overlook that ? It's from this section "Graphics processors can speed up password cracking by a factor of 50 to 100 over general purpose computers. As of 2011, available commercial products claim the ability to test up to 2,800,000,0n0 passwords a second on a standard desktop computer using a high-end graphics processor." --Sylye (talk) 05:09, 6 September 2016 (UTC)

Hello fellow Wikipedians,

I have just modified 4 external links on Password cracking. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:33, 11 December 2017 (UTC)

Password generation and storage apps

These (such as RoboForm) should be addressed in the article. Harry Audus (talk) 01:54, 7 July 2022 (UTC)

Block chain

Surely block chain has changed the whole password environment. Harry Audus (talk) 01:58, 7 July 2022 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Password_cracking/Archive_1&oldid=1244265106"