PPTPD password restrictions/custom chap-secrets

[MDB_Knox]

Specifically, my question is why are certain special characters (notably ampersand) are prohibited from being used in the chap-secrets file for pptpd passwords?

I am assuming that this is probably due to a limitation of the webgui handling, because if I hand edit chap-secrets and then restart pptpd, it works just fine.

Which brings me to my next question...
Is there any way you can think of through postconf scripts, etc to append something to the chap-secrets file every time before pptpd is actually started? Basically, is there any way to make my custom password stick in the file???

I've tried using a .postconf to do it, but it doesn't seem to work -- and I can't easily just reroute the options file to a different chap-secrets because it seems to get overwritten by the webui too.

I can probably get it to work by mangling things totally by hand -- and completely breaking the webui for VPN (which I do use fairly often for OpenVPN nailed routes) or having it break my settings whenever I try to update anything else.

Any suggestions?


Basically, I have quite a few legacy data collection devices out in the field that use an ampersand in the password that there is basically no way to easily change. I all else fails I can just disable PPTP in the router and forward it on to a secondary CentOS box behind the router, but that actually presents a few other headaches (specifically, that would be the ONLY thing said CentOS box would still be doing -- and we were hoping to get rid of it).

And, as a bit of a side note, is there any specific reason that the number of simultaneous pptpd connections is limited to 10 in the webui? Why should it even BE limited in the webui???

 

[sfx2000]

CHAP is kinda funny - but consider US-ACSII A-Z (upper/lower case) and 0-9 only... no puncs, flavor characters.. (obviously from a dev perspective, stay away from UTF-8 on CHAP/MS-CHAP)

16 octets (8 bit characters) is the max - anything less is padded by zero's/null's, and anything longer is discarded if I recall correctly... check the RFC to be certain...

MS-ChapV2 is the strongest cipher for CHAP on PPTP that is interoperable across OS platforms - but it's generally broken for those who are really interested in what you're doing (CHAP can be detected over the air/over the wire, but someone has to look for it and get interested in breaking it)

That being said - it's faster than OpenVPN if one just want to geo-unlock content via overseas VPN...

 

[MDB_Knox]

If you are speaking specifically of MS-ChapV2 then according to RFC2759 the input password specifically allows for 0-256 unicode characters -- which basically means that punctuation/special characters are allowed. And I can specifically attest that pptpd DOES handle the ampersand character among others without issue -- because I have numerous devices in the field that have been using it to connect to an existing server for YEARS now. And, I can specifically attest that it DOES work on the MerlinWRT platform if I hand edit chap-secrets. My question is whether or not there is a (simple) way to make my changes "sticky" (and why they are disallowed in the first place). The issue being, I have legacy devices in field that can't be updated that already use a password that includes an ampersand.

From a security standpoint, I'm not worried about someone breaking MS-ChapV2 anyway, because they would need to be able to intercept the initial DES handshake anyway -- and for the devices in question, that would either be the carrier themself or someone on the backbone directly snooping traffic (i.e. government agencies), and if they want my data, I don't really care. I'm just trying to find an easy way to use the router as the VPN connection point rather than having to maintain another secondary server behind it (which, if all else fails, I could probably just hack together an RPi2 or an old RT-N16 running pptpd via optware).

I'm just trying to figure out if there is a simple way to solve my problem without having to resort to multiple box solutions (worst case, I could always just modify Advanced-VPN-pptpd.asp, but that would essentially mean forking MerlinWRT and rebuilding everything, which is more effort than I care for right now -- especially as it means I'd have to resurrect a VM to use for cross-compiling).

 

[sfx2000]

If you are speaking specifically of MS-ChapV2 then according to RFC2759 the input password specifically allows for 0-256 unicode characters

Yep, but not all platforms that support PPTP support unicode (or ISO-Latin or UTF-8) - esp. for VPN appliances, so to be on the safe side, US-ASCII is recommended (note, not mandatory).

PPTP (and CHAP/MS-CHAP/chap whatever) has been so thoroughly broken from a security perspective, it's like a latch on a screen door - I still use it as a VPN of last resort, as it's firewall friendly, and just about every platform supports it natively.. tunnel it is (and reasonably fast at that) but secure it is not..