-4

I trying to avoid printing password in log. So in my log formatter class i search for a word "password" and then i trying to replace the value of password by *****'s. But now i m facing a issue like how to find the password when i have no password policy. MY CODE is :

class SecurityEnhancedLogFormatter {
private static final String[] keys= new String[] { "password", "pswrd" }; //No I18N
public String restrictPasswordEntry(String message){
    for(Object object : SENSITIVE_KEY_HASH_SET){
        String str = (String)object;
        while(true){
            if(message.contains(str)){
                int index = message.indexOf(str) - 1;
                message = message.replace(message.substring(index,message.indexOf(",",index)-1),"*****");
            } else {
                break;
            }
        }
    }
    return message;
}

in this how to find my password endindex when these passwords have no policy. That is for String "password" : jkd kjdd, kdjk*;'.,(this is example, the format can b anything)

sera
  • 27
  • 9
  • 1
    what is the difference between a string with password policy and one without? – XtremeBaumer May 15 '17 at 12:25
  • I think this is bound to fail. Either you know all passwords and can hence replace them (in which case, what do you do if a password is a common word or could otherwise occur as regular communication?), or you don't, in which case I don't see how that would be possible at all. But maybe I'm missing something. Or misunderstanding the whole question. – domsson May 15 '17 at 12:28
  • Wait, I think now I understand - the password *always* occurs right after the string `"password" :`, is that it? Maybe you can reword your question so it becomes a bit more clear. – domsson May 15 '17 at 12:30
  • 1
    Please say this is for a hobby project and not a production system. – Kayaman May 15 '17 at 12:33

3 Answers3

2

You are going down the wrong rabbit hole here.

You do not want to hope to find password used in arbitrary messages. Because chances are: your expectations about patterns break at some point.

The real point: don't try to use "technology" to solve a social problem.

Meaning: educate your team about reasonable rules regarding logging of passwords.

Like rule no. 1: never ever log passwords. Thus: sit down together; understand the problem; and make sure everybody agrees on the problem; and the solution that you want to put in place.

If at all; you would be looking into technology to treat passwords really special. For example by giving them their own class; and that class could overwrite toString() for example to make sure that you always "mask" your passwords; even somebody happens to do 

log("whatever: " + ... + password);

Edit on the comment: when you use a special class for passwords (not String!) then you can make sure that at least printing a map or list with those values will always result in an "****" string instead of clear text. And please note: you can choose to put a method like getPasswordAsClearText() to your own class (there might be a need for that) - but then you make it at least obvious what will happen here!

In other words: you want to make the Java type system work for you. Your approach is to use flat raw strings all over the place, and then "later on", after the facts you try to re-build "meta information" by hoping to find patterns within those flat raw strings.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • Actually the thing is for debugging we might use printing properties hashmaps etc., if in case anyone without knowledge printing the properties/anything which has password in log will be a problem right?. so i have to avoid those. In logger all kind of datasets will be printed as string so i want to handle it. – sera May 15 '17 at 12:40
  • I wholeheartedly agree on treating passwords separately; overwriting their `toString()` method is a very nice idea. Even better, of course, would be if the passwords would vanish as a hash in a database once entered and never occur in plain text ever again. But we don't know enough context. – domsson May 15 '17 at 12:43
  • @sera Passing passwords around in the system like regular data is always the wrong choice. Trying to fix insecure design with a solution like this is like putting band-aid on a shotgun wound. The name `SecurityEnhancedLogFormatter` is a misnomer, as the system obviously has critical security issues. – Kayaman May 15 '17 at 13:08
  • @Kayaman thanks for your inputs. this my fun time coding, i just trying to get solution for some of the worst case scenarios :) – sera May 16 '17 at 07:02
1

I have no idea what you mean by 'password policy' in this context, or why you think it would make any difference, but the problem with this code is that String.replace() returns a new String, and you are throwing it away, so it doesn't do anything.

user207421
  • 305,947
  • 44
  • 307
  • 483
0

Is there a reason you are passing passwords around as String objects, rather than as char[]? Using the latter would avoid this problem, as you'd get nothing meaningful in the logs.

Why is char[] preferred over String for passwords?

Community
  • 1
  • 1
user8014251
  • 1
  • Not necessarily. Somebody might be "clever enough" to use Arrays.toString() for that very array. Yes, using char arrays is a good practice; but **not** for this reason. – GhostCat May 15 '17 at 12:32