version 1.x authentication? certificate based?

[ganymede]

Can someone explain a little more how the authentication is going to work in 1.x version? does this mean no usernames and passwords anymore just certificates? and no ip address managed access?

I kind of always thought ip address access was a must... it limits a whole bunch of problems for example i run a ftp i give someone access to his ip range + a username and password, if you take the ip address out of the equation that means he can just go and give his username and password to anyone and they can use it... with a cert wouldnt he just give his username + password + certificate.... what i am saying is you cant exactly give anyone your ip range without proxying and going through a whole process with a certificate wont it just be about giving someone that cert?

i dont know too much about this just the basics... but please tell me the old method of authentication will still be around if we want to enable it.

[tuff]

lol, i think your jumping to WAY toooooo many conclusions there

ofcourse therell still be username/passwords & ident@ip checking, wouldnt it break the ftpd rfc if there wasnt

[darkone]

User needs username, password and certificate to login in ssl mode. Ip and ident checks are somehing that can be done using scripts/modules. I'd personally rather delete such user (it should be trivial to write a script that logs last N ips to eg. user database) - because even with ip-check, you can't be certain that he isn't running a proxy to let other users to use his personal account.

[darkone]

lol, i think your jumping to WAY toooooo many conclusions there

ofcourse therell still be username/passwords & ident@ip checking, wouldnt it break the ftpd rfc if there wasnt

No internal ident and ip checks are gone. Certficate based authentication is much safer and easier to administrate (eg. user can store his ftp client and certificates to memory stick, and use it anywhere he wants)

[ganymede]

yeah but ip checks are nice because they in a way limit locations - well limit better than anything else.....

How is the certificate based authentication going to work? i mean what protocol? how are clients going to communicate that certificate information to the server? what ftp clients support certificates.... dont say flashFXP(if it does) because not everyone wants to use flashfxp....

[ganymede]

oh and tuff as far as i recall he is breaking the FTP RFC or not?

[Harm]

yeah but ip checks are nice because they in a way limit locations - well limit better than anything else.....
I hope we will still be able to use the Host.Rules file for that.

[zpr]

how can i put my avatar ? and what option should i on to view 'registered user' under forum nickname ?

i'm blind or user cp options are miss sth ?

*** How about you dont post this sort of question on a thread that has nothing to do with this topic?

[tuff]

because even with ip-check, you can't be certain that he isn't running a proxy to let other users to use his personal account.

id say its much harder to use a proxy to spoof a users ident@ip then it would be for someone in there office to pick up there `usb stick` and use that

[ganymede]

see i just think that with things like a usb stick... you leave it on your desk the guy can steal your info or whatever - its a matter of stealing the cert, with an IP address it really limits a person to one pc... i find this really disapointing - blocking users by IP address is critical... some FTP owners only want their users to login from specific locations. The certificate should replace the encryption format, and not IP blocking they kind of have different functions....

i agree with tuff stealing a cert.... much easier than impersonating an IP - a lot of ftp owners are not going to like this - this is kind of taking ioFTPD off the top of the list for FTPDs, guess we will see what everyone else thinks.

an idea though : i know you can store a whole bunch of information in those certs why not put a specific ip in there.... , not perfect but just a thought.

[ADDiCT]

If the new io is anything like the old one, a simple script can deny a login when the remote IP doesn't match a certain list of allowed IPs / IP ranges, I don't think there is any reason to worry.

[Harm]

The new user / group databases will accept custom fields so adding ident@ip checks won't be that hard.

Also stealing the certificate isn't enough to be able to log in, you need the password.

[bigbighd604]

If the new io is anything like the old one, a simple script can deny a login when the remote IP doesn't match a certain list of allowed IPs / IP ranges, I don't think there is any reason to worry.

Yes,i agree with it. And if a script support a ip range such as xxx.xxx.xxx.xxx/xx is very good.The old io didn't support that format,so access control based on ip is something make me crazy :mad:

[EwarWoo]

Also stealing the certificate isn't enough to be able to log in, you need the password.

Well, if the whole idea is to have a memory stick with client and key so you can log in anywhere you would get the password as well as the key cos most people store password in site details for login in their ftp client.

1 option would be to tell users not to take their stuff on the road with 'em for security, however you cant be with all the users all the time, they will break that rule from time to time.

If a script comes out to support ip checking quickly and as easily as it works integrated not a problem. However if it doesn't I can see a lotta people fleeing back to Raiden. I certainly wont be upgrading to something that doesn't support IP checking, so I'm hoping current version carries on being supported until the script comes.

[PopWeasel]

Hrmf. I'm just wondering how people will generate certs for themselves, since I've not seen this done yet to date. Will there be a special program released to handle the job or will exporting certs be added to ftp clients so they maintain compatibility with new io. Also, when adding users..do they dcc/email you their physical cert or do they tell you their cert's fingerprint code....or? Just curious about how the new design will work.. I'm sure someone will do a public ident@ip script asap the new version is released for those who want to continue using that method of security so there shouldn't be any worries. ;) But I think the new certs based security is interesting enough to give it a try, we just need a little info on how it will work with adding users.

[ganymede]

sorry darkone looks like i started a riot! I agree with ewarwoo ip checking a necessity that will change the way i feel about the FTPD, personally i dont think this should be scripted functionality this should definitly be part of the core functionality.

secondly how is cert authentication going to work... thats my biggest concern - like what FTP client supports cert authentication...?! like how is the key exchange going to work? this is certainly going to f up my ioWeb project i just spend 6 months implementing SSL and now its going to be cert based... - no ftp clients supports this...??? or do they?

[tuff]

as i said, its much harder to steal an ip, than to steal a cert and sites.dat prolly stored in the same place

[PopWeasel]

sorry darkone looks like i started a riot! I agree with ewarwoo ip checking a necessity that will change the way i feel about the FTPD, personally i dont think this should be scripted functionality this should definitly be part of the core functionality.

secondly how is cert authentication going to work... thats my biggest concern - like what FTP client supports cert authentication...?! like how is the key exchange going to work? this is certainly going to f up my ioWeb project i just spend 6 months implementing SSL and now its going to be cert based... - no ftp clients supports this...??? or do they?

Probably they don't yet I imagine but the same could've been said for PRET and XDUPE at some point. And we all know how useful those features have been. So I think we just need to wait and see how it will work. Maybe there will be an 'XCERT' (eXtract CERT) feature made which when connecting to [new version of] io site will upload local cert -> site somehow. Darkone must be having a good laff at us trying to figure this out btw lol. :p :D

[PopWeasel]

btw, moving away from ip based security would allow not needing users' ip's to be in their userfiles anymore. So if a site box was ever 'taken' it would allow for more security/privacy as it would be much harder to find someone based on the cert of their pc than it would be to find them by the ip of their pc. :cool: Except that there would need to be an option to not log ip's as well. DrFTPd has this option so maybe it could be added to io as well. It just replaces 111.111.111.111 with xxx.xxx.xxx.xxx in the logs, or something similar. This would allow more anonymity (in light of recent events I think we all agree this is a good thing). I was just thinking of some of the implications of this new cert-based security and thought of this aspect of it. Didn't see it mentioned yet so thought I would go ahead and mention it. ;)

[tuff]

and not logging ips would make it also impossible to track anyone thats gained access that shouldnt have ;)

[PopWeasel]

hehe, true :)

[darkone]

as i said, its much harder to steal an ip, than to steal a cert and sites.dat prolly stored in the same place

This is false information. To steal certificate you need access to computer, and if certificate is stored in certificate store (which could be in remote loaction) - administrator level privileges. While to steal ip you need one of the following: access to computer, access to one of the routers between client and server or access to same ip range. Also, encrypting certificate and/or sites.dat is not such a bad idea (afaik. ffxp allows encryption of sensitive information)

And just like harm mentioned earlier, script may store arbitary data to both user and group databases. Adding ip/ident checks is rather trivial (though I don't personally see much use for ident check nowdays)

Implementation of client certificate check is trivial on both openssl and SSPI, and I've actually done this on both. On passive mode transfers, it's also neccessity for site to authenticate data connections as well, if site does not restrict data connection to allow access only from ip that control connection originates from.

[ganymede]

i cant say i agree with you on that darkone, you cant put an ip on a disk and give it to someone. certs are movable fullstop. to get someones ip you have to hack and install proxy or hack a router along the way.... the chances of hacking a router well... not many people will do that. if they hack your pc they going to steal your certificate anyways.

i think the bottom line is that this is functionality that almost every decent FTP server has and now its being removed because its so called obsolete - not true.

Furthermore many people are going to migrate to something that does have this functionality... i dont think an external script should be doing something that has evolved to be core functionality and in this present age vital functionality.

My biggest question is that why remove it? i mean people can turn it off so easily.... *!* :P your decreasing the functionality list of your own product! - here is a brilliant example of why certificates might not work... let say we have a company who by policy only want their staff to access their ftp from specific company locations(ips) using their login.... ? hows a certificate going to help you? its not...

now the obvious comeback to the above situation is get a script - thats not the obvious solution to someone who is paying. to someone paying its get a product that meets my requirements.

i think from a business point of view this is a mistake, the proposed solution sounds great. But in actual fact we are trading an apple for an orange - replacing something that does one thing by something that does another.....

i know i sound biased but to be honest i dont even use ip checking because everyone i know is on dial up we have shit lines and funny ranges in south africa - however a lot of people i know do and they think its essential. The only reason iam raising flags now is because i have been developing a .NET version of a HTTP web administration tool and get a lot of feedback from various friends etc who simply wont run it without without ip checking - and realistically what SiTEOP would install io without it.

PS - one thing that pisses me off and seems to happen a lot nowdays is as software developers release new versions of their software and 'upgrade' certain features by removing others they forget that there are people who only bought the product for the feature that was removed - which goes back to an earlier point what harm is there to leave it in.

[FTPServerTools]

Well it looks like I know what I need to build into the new ioFTPD as plugin. ip cheching, also with the ability to use dns names, and ident stuff... I hope us scripters get a pre beta 1.0 to play with and code for. :)

[ganymede]

i plugin is not what is needed here, the developers need to identify a basic need and implement it.

[EwarWoo]

The main problem with a plugin / script is it could be back to the old situation where some of the times that io gets updated it kills the script. And the script creator is away so it doesn't get updated. Someone else makes one. You end up with 8 or 9 versions not knowing which to use. You get used to one you find and like and the scriptor stops supporting it cos he runs out of steam. Etc etc.
And anyways, a function like that which is at the very core of modern FTP servers (try a poll, see how many consider essential) should be made a part of the core program by the developer, not added in by an unpaid scriptor. Don't get me wrong, I love what you scriptors do, I wish to hell I had a fraction of the skill, you're an absolutely amazing bunch, but its just not your responsibility and something so essential to the overall functionality should be fully supported and a responsibility, not a hobby.
Thats my opinion anyhows.

[ganymede]

Brialliantly put EwarWoo i couldnt have said it any better - and i fully agree.

[darkone]

There has been compatability have only arised with major releases (rewrites). However, as far as I can tell, there are no more rewrites coming any time soon after 1.0.

[tuff]

i have to also agree with ganymede, why remove something that already works to replace it with something no one wants?

keep ident@ip checking, if its not what someone wants, they can disable it, rather than force this change on everyone

i still believe ident@ip checking should be a core component, and not a script

who has actually been dreaming up these changes?

/me slaps d1

[SnypeTEST]

[my views on iO]
Hi everyone. d1 is taking his product to the whole market. The way I see it, iO (d1) is just trying to move away from the scene rules and make a product that is more of a versatile-industry related type of app (webhosting companies, etc). Adding more things that are relevant to the larger IT user base -- intensive security. His product needs to stand out in the crowd. And if this is the case, which it is obviously true [i hope....], then I am very happy with the changes that d1 is making. Instead of making zipscripts, communist-banana :), etc.. there will also be a need for scripters to create extensive plugins that show bandwidth usage per user hourly/min/sec, calculated statistics, http frontend, and "who's uploading crap to my server" and all that other junk businesses are interested in. Which will increase the userbase and an influx of scripters. I can't wait for 1.0 :rolleyes:
[/my views on iO]

[back on topic]
The whole cert thing is a great idea. As for the old method, an ITCL script could mostlikely take care of everything. and if changes happend in future releases of io, any scripter can edit the TCL script to work with the current release. d1 can make the TCL script himself too and keep it up to date if he wants, it would be convinient for those users who rely on the ip@ident method.
[/back on topic]

byebye

[ganymede]

snypeTest ... just out of interest what whole market are you talking about? and... secondly why take functionality that exists in an ftp daemon and remove it? why build a TCL script who cares? build it in.

d1 why not just put up a poll and see who wants what? and what harm is there in putting ip checking? like really come on here... by taking out a feature your opening up your product to competing products doesnt matter what industry you are aiming for... its such a simple thing... why risk loosing users for something so trivial.....

[SnypeTEST]

whole market.. as in this FTPD is no longer just going to be targeted to the "scene". Now even companies will start using the FTPD for their win Servers. such as webhosting companies.

Let an external module take care of that. Acouple Reasons:

1) its not like your going to upgrade to v1.0 as soon as it comes out anyway. d1 said himself, all scripts will not work because of the new core.
2) ip@ident is a simple thing. infact an external wrapper can be created to handle this so it doesnt have to rely on ioFTPD versions.

user -> identd wrapper -> (any)FTPD

( thus why d1 says that this method is not secure at all. it can be faked very easly. )

[darkone]

secondly why take functionality that exists in an ftp daemon and remove it?

Because ioFTPD 1.0 has nothing to do with previous ioftpd's. (except the name) Just wait and see.

[darkone]

Also, did I already mention; passive mode (SSL) transfers require certificate based authentication.

[ganymede]

darkone throw a dog a bone here and just implement a user ip blocking system!

not to worried about the second point... new functionality is always good.

[darkone]

I'll guess I could implement it as example script/module. However, I do not wish to include ip table in database by default.

[Harm]

I don't know many things about client certificates. I'm sure there's a way to secure them even if they're stored on some usb stick. Could you enlighten me ?
On another side, how will it work with other ftp daemons ?

Talking about companies that want to restrict the access to their ftp servers, there should still be an ip/host based access control like what we currently have with Host.Rules. Again, could you confirm this darkone ? I must also agree with the fact that ident might be "fun" but is very easy to fake nowadays.

Since tcl will still be there, adding a script to check the ident@host of the user on connect will only take a few lines of code. It will even bring the ability to add advanced regular expressions support or other kind of comparisons you might think of.

[ganymede]

back to my earlier point - as long as inicom want to maintain the ip script there isnt a problem. Harm... if you going to use a host.rules file i suggest you use a decent firewall instead.... again this does not solve the problem - you cant limit certain people to certain addresses eg: managers can login from anywhere & peons can login from work only - again a certificate cannot help you there.

[ganymede]

dark1 quick question about certificates - will it be like the current io where you force certain users to use them and for example localhost not to?

[darkone]

dark1 quick question about certificates - will it be like the current io where you force certain users to use them and for example localhost not to?

If user has certificate(s) specified, he is expected to use one. Also note that certificate based authentication only works in SSL mode.

[ganymede]

can you run SSL mode without certificates.... AUTH SSL / AUTH TLS