Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom separation character for prince cracking #2268

Open
func0der opened this issue Sep 12, 2016 · 14 comments
Open

Custom separation character for prince cracking #2268

func0der opened this issue Sep 12, 2016 · 14 comments
Assignees

Comments

@func0der
Copy link

I would like to a custom separation character for the prince cracking.

Chaining words is a common practice, they may be separated by spaces for example.

Do you see a chance for that?

@jfoug
Copy link
Collaborator

jfoug commented Sep 12, 2016

Should it be a character, or set of character???

My Password
vs
My-Password
vs
My:Password
vs
My_Password

Here the set is the 4 characters '-_ :'

@func0der
Copy link
Author

For my usecase I basically just need one character (the whitespace). But it may be useful to have multiple, maybe even a group.

@jfoug
Copy link
Collaborator

jfoug commented Sep 12, 2016

I would think a 'group' would be much more powerful and useful, without too much additional coding.

@magnumripper
Copy link
Member

Ideally this should be requested / implemented in https://github.com/hashcat/princeprocessor and then we'd merge it from upstream.

@frank-dittrich
Copy link
Collaborator

We might want to coordinate PRINCE mode enhancements with hashcat.

@magnumripper
Copy link
Member

I beat you by 15 seconds @frank-dittrich 😉

@frank-dittrich
Copy link
Collaborator

@magnumripper

I beat you by 15 seconds @frank-dittrich

I was too busy all day, and assumed you or @jfoug would suggest that, anyway.
Now I first read all the other mails, then replied.
And when I pressed the [comment] button, I saw that incoming mail.

@magnumripper
Copy link
Member

Anyway I definitely can see a use for this. Hopefully it can be added with little performance impact.

@frank-dittrich
Copy link
Collaborator

Also, for '-_ :'
Should PRINCE mode try each separator for a combination of 2 words of given length before processing the next combination of 2 words, or should PRINCE mode just use '-' (the first separator) for all the combinations of 2 words of a given length before using the next separator?

For combinations of 3 words, should prince mode generate

one-two-three
one_two_three
one two three
one:two:three

before generating combinations like one-two_three etc.

(I know that I am "simplifying" the way PRINCE works, but I just wanted to demonstrate that there's more than one way to implement such an extension.)

There might be a several config or command line options, and it is not easy to decide which default logic might provide best results.

@jfoug
Copy link
Collaborator

jfoug commented Sep 12, 2016

Personally, from what I have seen in 'current' RW data, your method 1 would be best. Most RW appends are done using the same character. However, some of the notes / documentation in things like diceware, do list to use 'random' symbol characters between the simple words. If I were to use diceware, I certainly would use random character separators, since that would add additional bits for each word. If using the same characters, you only add the additional bits 1 time and none of the other separators add any additional security. But most users DO use the same separator (which is still USUALLY no separator).

So, yes, there may have to be several parameters to fully utilize this. It may even be best to provide priority:

so,

onetwothree    (is tested first)
one two three   (tested 2nd)
one-two-thee
one_two_three
and finally
one:two:three

Then there may have to be other ways to order combinations. Note, things very quickly explode (combination function), and unfortunately the combinations are not going to be uniform likely. However, figuring out which combinations are more likely is probably not going to be an easy to do task.

@func0der
Copy link
Author

I think you are overthinking this right now, @frank-dittrich . What is talking about is basically just using one separator for the whole password. Everything else would be possible, but I think most ppl would only use one separator, like @jfoug pointed out.

The group feature would be usefull, too, but basically you could run different versions of the same command in batch for starters. That way you would only need one separator parameter for now and the rest would follow.

@magnumripper
Copy link
Member

It turns out this is already requested in hashcat/princeprocessor#49

@drzraf
Copy link

drzraf commented Nov 27, 2019

Wouldn't using a kind of first-pass-rule processing for separators be a less-disruptive way to implement it ?

  • would not affect most of the existing pp.c code (nor keyspace generation/options/...)
  • would give the flexibility of rules to define concatenation or simply limit it to a "separator-rule".

Just a quick example out of my mind:
With:

[List.Rules:Separators]
SEP[@-:_\0]   # expands each combination to `<prince-elem-cnt-max - 1> * <num-separators>` concatenated combinations.

If the wordlist contains ("foo" "bar" "baz") then john --prince --prince-elem-cnt-max=3 --separator-rule:Separators --stdout would provide

  • foo@bar
  • foo:bar
  • foobar (the \0 separator)
  • `[...]
  • foo@bar@baz
  • foo@bar-baz
  • foo@bar:baz
  • [...]

Afterwards, normal existing rules pass would apply to each of them if requested by --rules.

Another possibility: Concatenate words using a truly unique character and rely exclusively on a the current rule pass assuming a rule would be able to:

  1. Replace...
  2. A given character...
  3. At one or more position(s)...
  4. By a set of characters.

Example: Combination list before rules apply:

  • foo§ar
  • foo§bar§baz

The rule:

[List.Rules:Separators]
RR § * [@:]

The results:

  • foo@bar
  • foo:bar
  • foo@bar@baz
  • foo@bar:baz
  • foo:bar@baz
  • foo:bar:baz

@solardiz
Copy link
Member

I happen to have described a workaround in https://www.openwall.com/lists/john-users/2024/05/15/3 - start each word with a capital letter, then detect those from rules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants