Why PasswordField use String instead of char[] in Vaadin?

Question

String is vulnerable for password values. I noticed that Vaadin PasswordField manipulates password as a String.

Following is default constructor of PasswordField,

public PasswordField() {
  setValue("");
}

My questions :

Is it safe to use PasswordField in Vaadin ?
What internal API does to assure the safety of the password ?

I don't see how using a string is vulnerable. Strings are also used in other java frameworks. Besides, regex could be used to set a pattern for the password. — cdaiga, Aug 11 '16 at 06:47
@cdaiga [see this](http://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords-in-java) where they explain why `char[]` is more secure than `String` — Paolo Forgia, Aug 11 '16 at 06:49

score 5 · Accepted Answer · edited May 23 '17 at 12:02

TL;DR Vaadin PasswordField is a simple TextField. The input is hidden just in client-side, in server-side is transmitted in clear text.

Although you can use getConvertedValue() and setConvertedValue(Object value) for getting/setting the value in your own type. Note that you have to set the setConverter(Converter<T,?> converter) before using it.

Here you have an example of how to use properly the conversation: Creating your own converter for String - MyType conversion

FULL EXPLANATION

Vaadin TextField, PasswordField and TextArea are all children of AbstractField<String>.

In detail:

java.lang.Object
  |_ com.vaadin.server.AbstractClientConnector
       |_ com.vaadin.ui.AbstractComponent
            |_ com.vaadin.ui.AbstractField<java.lang.String>
                 |_ com.vaadin.ui.AbstractTextField

PasswordField works with String because of its parents, otherwise it should have implemented AbstractField<char[]>.

In addition in the PasswordField section from Vaadin Docs says explicitly:

You should note that the PasswordField hides the input only from "over the shoulder" visual observation. Unless the server connection is encrypted with a secure connection, such as HTTPS, the input is transmitted in clear text and may be intercepted by anyone with low-level access to the network. Also phishing attacks that intercept the input in the browser may be possible by exploiting JavaScript execution security holes in the browser.

Although AbstractField<T> has getConvertedValue() and setConvertedValue(Object value) which allow to get/set the value in the Object you prefer. Note that before using it you need to set setConverter(Converter<T,?> converter).

Here you have an example of how to use properly the conversation: Creating your own converter for String - MyType conversion

In short from the example:

Name is a simple POJO with firstName and lastName fields and their getter/setter.

Converter class

public class StringToNameConverter implements Converter<String, Name> {

    public Name convertToModel(String text, Locale locale) {
        String[] parts = text.split(" ");
        return new Name(parts[0], parts[1]);
    }

    public String convertToPresentation(Name name, Locale locale)
            throws ConversionException {
        return name.getFirstName() + " " + name.getLastName();
    }

    public Class<Name> getModelType() {
        return Name.class;
    }

    public Class<String> getPresentationType() {
        return String.class;
    }
}

Main class

Name name = new Name("Rudolph", "Reindeer");
final TextField textField = new TextField("Name");
textField.setConverter(new StringToNameConverter());
textField.setConvertedValue(name);
addComponent(textField);
addComponent(new Button("Submit value", new ClickListener() {

    public void buttonClick(ClickEvent event) {
        Name name = (Name) textField.getConvertedValue();
    }

}));

Full source

Morfic · Answer 2 · 2016-08-11T10:20:45.440

A little late to this party, but I'd like to add my 2 cents to what's already been discussed.

It may be purely confort and code reuse, as PasswordField just extends AbstractTextField on the BE side which is basically an AbstractField<String> so all the value manipulation logic, event handling, etc is already there.

Otherwise one would probably have to implement an AbstractField<char[]> and copy-paste pretty much everything from AbstractTextField just for this. Or to generify AbstractTextField or something similar...

Either way, as already stated, an attacker would require access to the server to dump the memory, case in which you may have bigger problems, be it from outside or inside the organisation (there surely are cases in which own employees have done harm for some reasons) :-)

Regarding the FE, the VPasswordField counterpart creates an input of type password, and the security concerns in respect to the the FE-BE communication have already been discussed in Paolo Forgia's answer.

score 2 · Answer 3 · answered Aug 11 '16 at 06:56

When vaadin codes runs in your web browser it is not in a JVM anymore, so using String is ok in this case. The password will be stored as Java String in the server side, so in order to access that password String, an attacker has to access your server.

You should be looking at how that password field is handled in the generated javascript.

Why PasswordField use String instead of char[] in Vaadin?

3 Answers3