Core FTP

Hi there

The way security is configured in CoreFTP seems really screwy. I work for a company called YYY. I have:

CoreFTP 275
FileZilla 3.1.3.1

Core hosts one domain. Among other things the following are ticked:
YES "SSH/SFTP Only"
YES "Allow key auth"
YES "Key auth only"
NO "Enable WinNT"
NO "Enable Active Directory"

For accounts I have:
abc_pubkey (using acme_public_key keyfile. NO "User does not require key auth")
xyz_passwd (using YYY company certificate, I'm not sure why, didnt configure it. YES "User does not require key auth")
cjard_pubkey (using my own public key made with PuTTYgen just now. NO "User does not require key auth"
cjard_nokey (not using any public key file. YES "User does not require key auth")

We will receive a file of a company called ABC. We have their public key and the abc_pubkey account is configured to use this.
We will receieve a file off a company XYZ and they have no key pair, so it's just password auth for them

I also created another 2 accounts for me and configured ONE of them to use my personal public key that I made just now, and the other one has a BLANK in the "ssh pub cert" box


I find to my dismay that, for those accounts XYZ_PASSWD and CJARD_NOKEY, that if I load my private key into FileZilla, I can access those accounts with the wrong password or NO password!
It seems CoreFTP doesnt even challenge FileZilla for the password. It just decides to do key auth, filezilla knows of one key, CoreFTP uses every key it knows of (?) and lets me into any account!

I'm now seriously concerned that having installed ABC's public key on ABC's account, that some minion at ABC will be able to figure out we do business with XYZ, and just attempt a login to XYZ_PASSWD account and core wont even challenge for the password, but let them in based on their private key! EEK!

Why? Why, if I have a private key that matches one account, can I access any other account that has a password but no key file [cjard_nokey] (or a dummy keyfile [xyz_passwd])


-

The security settings need a re-design. The domain screen should have tickboxes like:

"Authentications allowed on this domain"
Pub/Priv key
Password
WinNT
ActiveDirectory
None

And the account screens have higher priority settings for the same. If only password is ticked, then logging into that account with an SSH key should NOT be possible, much less the key from another account!

Right now, I'm not sure what combination of things to tick to allow password-only auth, or if it's even possible

-

Also, another small thing; could you please tidy the UI up a bit? It looks like a baby has thrown it together. Organise and align the controls, and use some capital letters/more words in labels like "ssh pub cert"

Update the documentation and actually put some content in it; it says nothing about half the options available, and what is there is, frankly, crap. Sorry to be scathing, but it's apalling

Honestly.. this software needs a good polish to make it look professional; right now it looks like a beta test where some developer has thought "ooh, another feature we can add.. throw another checkbox for it at a random place on one of the screens and bang some code behind it"

As an example: Tick SSH only. Some items grey out. Now tick Disable (all items are greyed out). Now untick Disable (all items are enabled). Hang on.. werent some supposed to be greyed out when we ticked SSH only?

As another example: True/False decisions are generally supposed to be POSITIVE. As such "User does not need blahblah" is NOT a good checkbox.. Ticking to say YES to a negative is less intuitive. Consider the following statements:
"True; Jim was at the park last night"
"False; Jim wasn't at the park last night" <-- does that mean he was, or was not at the park?

Keep it simple

If you need some more HCI commentary or a more in-depth explanation of my issues with the UI, let me know

OK well you need a better layout of the security window with some radio buttons:

[code]
( ) No key authentication
(o) Allow key authentication
( ) Require key authentication
Path to key file: [c:\program files...]

( ) No password authentication
(o) Allow password authentication
( ) Require password authentication
Password: [******** ]
[/code]

If "no" is selected, then that option is not available for auth
If "allow" is selected, the option can be used but doesnt have to be
If "require" is selected, that option must be used

If someone wants both passwd and key, they must set REQUIRE on both. If they want either, they choose ALLOW on both


Actually designing the UI well can mean you dont have to write lots of documentation..


..and I can still connect to any passworded account using a private key from another account's public key.. Try it yourself:

Set the domain to SSH/SFTP, Allow key auth, Key auth only. All other options disable
Now make one account with no password, a public key chosen and NO TICK in "user does not require key auth"
Now make another account with a password, NO public key chosen, and TICKED "User does not require" ...

Now in FileZilla (the client I'm using to report this bug).. [i](Note that you'll have to get PuTTYgen to make the keys because FileZilla does not understand the private key Core makes) or provide me with an email address and I will email a key pair to you that works with filezilla)[/i]
register the private key, and then attempt to connect to the PASSWORDED account, using any old random password

It connects!