Authentication Support

[Prasad Shenoy]

Is the weak NTLM v* authentication support in ZAP due to the fact that it is built on Paros? I have always had a problem with the missing or lacking support for NTLM authentication in Paros. Is this a existing feature request? or can be added? 

Also, I have submitted a feature request to mask the passwords on the Authentication settings page. 

Thank you.

[ ~ Prasad |  @prasadshenoy  ~]

[psiinon]

Yes :)
I cant see an existing request for it, but feel free to add it!
I must admit I dont do any assessments on apps that use NTLM, but it would be really good for ZAP to support it properly.
That could be a useful project?

And good suggestion for the passwords :)

Many thanks,

Simon

[Prasad Shenoy]

I would like to work on the password masking issue item. 

[ ~ Prasad |  @prasadshenoy  ~]

--
 
 

[psiinon]

I've assigned the issue to you - go for it!

[Prasad Shenoy]

Would there be any objection to changing the look and feel of the authentication options panel? The current one uses AbstractTable and model is not very flexible from what I could deduce. I would like to make the table more dynamic enabling users to add and delete authentication options quickly and easily. I have some ideas but want to get the pulse of the group.

Any advice would be appreciated. 

[ ~ Prasad |  @prasadshenoy  ~]

--
 
 

[psiinon]

Go for it!
I dont think thats changed since Paros, so is due for an overhaul ;)
We actually use that type of table in other options panels as well, and I agree its not ideal.
If you come up with a better one then we should roll it out to those pages as well :)

Cheers,

Simon

[thc202]

Hi.

If I am understanding you correctly, regarding the table model, you only need to implement the methods to add and remove the HostAuthentication(s) in the class OptionsAuthenticationTableModel.

Curiously, I'm about to finish some changes on how multiple related options are managed (which includes the management of the host authentication) and other details regarding the usability of all the options.
Currently there are several ways, which can be grouped in 3 categories, on how those options are managed. All of them have some issues that impair the usability, from minor to greater:
 1) The options are added, removed and edited directly in the table (example: "Session properties" > "Exclude from proxy"). The main problems are:
  - to remove an option you have to delete the contents of the cell;
  - (a special annoying one) when editing the options if the cell doesn't loose the focus and you close the dialogue the option doesn't get updated;
  - there's no way to temporarily disable an option (not related to how the management is done, but it's worth remarking it, as most of the multiple related options, if not all, should provide a way to enable/disable them);
  - it may happen that the last row is not always shown immediately to allow the addition of a new entry;
 2) The options are added, edited and removed with buttons, the fields of those options are shown beneath the table listing the options (example: "Options" > "Applications"). There are minor problems related to how the buttons work and the fields being always editable.
  - If by mistake you press the wrong button (pressing "new" again) it will result in a lose of the additions;
  - the fields are not updated if the keyboard is used (not related to the management, but it's worth pointing, as this is a usability detail that should be taken in consideration);
 3) The options are managed in a text area, this is, by far, the least usable (example: "Options" > "Connections" > "Skip IP addresses (...)" text area). There's no need to say too much about this way (it, almost, speaks for itself), the user has to manually select the correct option to remove it, which can be hard to pinpoint if you have a lot of those and there's no way to disable an entry.

Not all the issues are described, but, more or less, the most relevant to the ways of management, are.

The changes are an attempt to normalise how the management of multiple related options is done throughout ZAP, so, hopefully, the user doesn't have to jump from a way of doing it to another one completely different. It should also allow the user to specify some details of those options, in the case of the "Exclude from proxy", there should be an easy way to specify an URL in plain text without the need to manually "quote" the "regular expression", more over it allows to introduce other conditions not restricted to a specific component of the message like the URL (may be useful if the user wants to exclude files that are greater than a specific size (determined through the "Content-Length" header field)).

Some of the other details regarding the usability of all the options:
 - When an option is disabled, other options that depend on the disabled option shouldn't be reset. If the user only wanted to disable temporarily the option, he won't need to fill all the fields again (example: "Options" > "Connections" > "Use an outgoing proxy server" if it is unchecked the "Address", "Port" and "Skip IP addresses (...)" are reset);
 - Addition of a button to reset the options to default values.
 - The components should resize correctly when the dialogue is resized (example: "Options" > "Connections" > "Skip IP addresses (...)" the text area doesn't resize as most as it should).

I also want to allow the user to maximise the "Options" dialogue.

I was going to commit the changes (when ready) without asking about the changes to the develop group, as there are much more advantages to what is being done now that it seems to me that it's a natural change and that it inevitably would happen (there are some issue(s) about the usability of some options).

But as this subject as been brought here, I've attached a working example on what the management will look like (if everyone agrees with it). If anyone wants to see it and give some feedback, it would be greatly appreciated.


Best regards.

[psiinon]

Awesome!

This has been long overdue, but also a significant undertaking that I've not been able to face looking at ;)

I'll have a play with your changes as soon as I get a chance.

Many thanks,

Simon

[Prasad Shenoy]

This is very timely. I was knee deep into the authentication options panel already :). All the points you made for Option 1 directly apply to the Authentication panel. The JTable implementation is very rigid so I started looking at some other things but couldn't find anything great. Will check out your changes and opine shortly. 

Thank you.

[ ~ Prasad |  @prasadshenoy  ~]

--
 
 

[psiinon]

I think that looking really good :)
The buttons are much clearer and easier to use than the current 'in line' table editing.
I think we should change all editable lists to work this way - maybe implement a generic control to do this that we can reuse? ;)

Very minor point - in the 'Confirm remove' dialog the buttons are labelled 'Yes' and 'No'.
I think the current advice is to avoid these sort of labels as they can confuse users.
Instead use labels that people can quickly understand without having to (mis) read the question, eg 'Delete' and 'Cancel'.
Obviously its an easy fix!

Cheers,

Simon

[psiinon]

Hi THC - have you made any more progress with the options?

Cheers,

Simon

[Prasad Shenoy]

Simon,

I apologize for not being able to contribute much in past few weeks. I was occupied with a few other things and expect to get back in routine ASAP. Please keep the Password Mask feature assigned to me as I continue I work on it :). At some point soon, I will take a look at the proposed changes by THC and am sure that will address majority of the UI issues we are discussing today.

Thank you,

Prasad N. Shenoy

--
 
 

[thc202]

Hi.

It was put (a little) aside some time ago but should be ready for the next weekly release (the needed changes in the help pages probably not).

Regarding the previous message, sorry for not answering before.

Thanks for the feedback! It's really appreciated.

Yes, the idea is to change every listing/management of multiple related options to use the same component, so the UI and management of those options is consistent throughout ZAP.

OK, thanks for the advice, I'll change the labels.

Thanks.
Best regards.

[Prasad Shenoy]

thc202,

I agree. This looks really good and closer to what I had anticipated. What is the plan now? I would like to work on password masking to begin with. 

Thanks

Prasad

--
 
 
<options.jar>

[thc202]

Hi.

There are some issues that are delaying the commit of the changes, as I wanted to have it already included in the previous weekly release, but you should be able to make the required changes to display the masked password without problems as the model (OptionsAuthenticationTableModel) and panel (OptionsAuthenticationPanel) will be the same, or it's also to be masked in the configuration file?

The password should also be masked in the dialogues to add and modify the host authentication?

Best regards.

[Prasad Shenoy]

This idea is to mask the passwords via dialogs. That would be on Authentication panel and other places where passwords are requested, in a consistent manner.

Are you sure I don't need to wait for your code to be committed? There won't be any Mask Password button in the current layout so how do I write a listener to mask/unmask etc? I might be missing something. If so, please help me understand.

Thank you,

Prasad N. Shenoy

--
 
 

[Prasad Shenoy]

Any thoughts or suggestions on this? 

Thank you,

Prasad N. Shenoy

[thc202]

Hi.

Sorry for not answering sooner to the previous message.

It was possible to mask the passwords, at least in the table as the dialogues didn't exist, without the need to wait for the changes to be committed because I thought that the button (probably it would be better to use a check box to enable/disable the masking of the passwords) would be added by you to the "Authentication" options panel. The check box that I've added to the previously attached example was only to exemplify where other options, that would affect the managed options, would be placed, it was not meant to be committed.

I've committed the changes that affected the "Authentication" options panel, so you can also change it to mask the passwords in the add/modify dialogues.

Regarding the masking of the passwords, in the table, you could simply return always the same masked string, like "*****", when the option is enabled and return the password in clear text, as it is now, when disabled. About the dialogues it could be changed to show two JPasswordFields (which would replace the current text field) when enabled and the current text field when disabled. As for the check box to enable/disable the masking, it would be better to have a warning/confirmation dialogue, when disabling, to warn that the passwords will be in clear text and confirm that it's sure about it.

Best regards.

[Prasad Shenoy]

THC202,

Thanks. That was helpful. 

I have made the required changes to the Authentication options panel to be able to mask the password. One question though, for the general population as well - My preference is to leave the password masked (**********) in the table/list view while offering a mask/unmask choice only on the Add/Modify dialog. This is a bit more secure whilst bit inconvenient. 

What is the general though on this?

Thanks.

Prasad

--
 
 

[thc202]

Hi.

I would still allow the current behaviour, that is, show the passwords in clear text in the table.

Best regards.

[psiinon]

Yeah, I think we should have an option for showing the passwords.
Maybe we could have a checkbox in the Options/Display screen?
I dont mind which way round the default is.

Cheers,

Simon

[Prasad Shenoy]

Oh yeah for sure, there needs to be a way to see the clear text password. My question was more around whether there needs to be that provision in the Add/Modify dialog or also on the table that lists all authentication options. In that regards, I followed THC's advice and am building the option in the table view as well.

Will get back in touch shortly.

Thank you

Prasad

--