NEW Package: freeRADIUS 2.x
-
Hi ,
i tried the package with otp and it work's but if client is behind server time (my mobile provider is 30 sec in the past !) i am not able to login (tested with radtest) .
worked like a charme with online mtop calculator but never with DroidOTP and "TIME OFFSET 30 or -30 "
Maybe i am doing something wrong but i do not know what.
The OTP Passcode from the mobile phone is 30 sec. later the same as the online calc did.Maybe someone can give a hint or maybe minus offset is not possible ….
regards
max
-
Hi ,
i tried the package with otp and it work's but if client is behind server time (my mobile provider is 30 sec in the past !) i am not able to login (tested with radtest) .
worked like a charme with online mtop calculator but never with DroidOTP and "TIME OFFSET 30 or -30 "
Maybe i am doing something wrong but i do not know what.
The OTP Passcode from the mobile phone is 30 sec. later the same as the online calc did.Maybe someone can give a hint or maybe minus offset is not possible ….
regards
max
Hi,
Did you calculate the Epoch-Time?
1. Write down the first 9 digits of the Epoch-Time on the client.
2. Check with date +%s the Epoch-Time on your FreeRADIUS server and write down the first 9 digits.
3. Subtract both values, multiply the result with 10 and enter the value in this field. (Default: 0)But in general it should not neccessary to change this if your mobile device changes its timezone automatically.
Further you can try increasing the "OTP Lifetime" in freeradius –> settings.
You can set it to 6 which means 60s. Even if the mobile clients always generate new keys every 30s it should be possible to use a generated key 60s instead of just 30s.The more you increase this time the more "insecure" OTP will become. Probably noone will get access with a key (without PIN) which has a lifetime of a few minutes.
---- edit ----
You are right. The script does not accept negative values. You could modify the script here:
freeradius.inc
line 4027
replace:EPOCHTIME=`expr \$EPOCHTIME + \$OFFSET`with
EPOCHTIME=`expr \$EPOCHTIME - \$OFFSET`Could be something what should be added to the GUI.
-
Hi,
yes i calc the epoch time like descript on the web interface:
(9digits (from left client time) - 9digit (from left server time)) *10 = -30date +%s = 10digits, so why the hell not taking (10digits (from left client time) - 10digits (from left server time)) = 30 ?? (or if 39 nearer 40 than 30 !!)
It's not a problem of the timezone it's a mobile provider problem; the android is 30 sec in the past.
(Is the offset 1 equal 1 hour, i hope not.)If i set the lifetime on server side higher than on the client (DroidOTP is fixed to 10 sec lifetime) than i had guess/try 6 keys maybe on is working not a good idea.
I know to solve the problem with manual set the client time but i want to find out how it work with time offset and maybe there is a bug or a wrong hint on the webinterface
regards max
–----edit----
The Gui save the Offset in the right way:/usr/pbi/freeradius-i386/etc/users
"otpuser" Auth-Type = motp
MOTP-Init-Secret = 912ae1361854139e,
MOTP-PIN = 1234,
MOTP-Offset = -30Use Freeradius teh otpverify.sh script ? If yes then there is the faulty part
OFFSET=
echo -n "$5" | sed 's/[^0-9]/0/g'
[[/sub]
-10 is then 010….
should beOFFSET=
echo -n "$5" | sed 's/[^0-9-]/0/g'but is a little be dirty could also be 1-0 …..
-
Hi,
yes i calc the epoch time like descript on the web interface:
(9digits (from left client time) - 9digit (from left server time)) *10 = -30date +%s = 10digits, so why the hell not taking (10digits (from left client time) - 10digits (from left server time)) = 30 ?? (or if 39 nearer 40 than 30 !!)
It's not a problem of the timezone it's a mobile provider problem; the android is 30 sec in the past.
(Is the offset 1 equal 1 hour, i hope not.)If i set the lifetime on server side higher than on the client (DroidOTP is fixed to 10 sec lifetime) than i had guess/try 6 keys maybe on is working not a good idea.
I know to solve the problem with manual set the client time but i want to find out how it work with time offset and maybe there is a bug or a wrong hint on the webinterface
regards max
–----edit----
The Gui save the Offset in the right way:/usr/pbi/freeradius-i386/etc/users
"otpuser" Auth-Type = motp
MOTP-Init-Secret = 912ae1361854139e,
MOTP-PIN = 1234,
MOTP-Offset = -30Use Freeradius teh otpverify.sh script ? If yes then there is the faulty part
OFFSET=
echo -n "$5" | sed 's/[^0-9]/0/g'
[[/sub]
-10 is then 010….
should beOFFSET=
echo -n "$5" | sed 's/[^0-9-]/0/g'but is a little be dirty could also be 1-0 …..
Did you read what I wrote about the part on the freeradius.inc ?
-
Yes i did.
But if i do it like you said then the offset is always minus.
In freeradius.inc
there is the same 'sed' in line 4006:OFFSET=
echo -n "\$5" | sed 's/[^0-9]/0/g'regards max
-
Yes i did.
But if i do it like you said then the offset is always minus.
In freeradius.inc
there is the same 'sed' in line 4006:OFFSET=
echo -n "\$5" | sed 's/[^0-9]/0/g'regards max
Hi max,
can you please replace the following two files and try again if it works now?
You now have to enter + 30 oder - 30
It is described on the GUI. -
Hi,
sorry for the long delay. Your scripts are not working. I did some investigation on EPOCHTIME and extend the freeradius.inc with some logs.
I found out that the Offset 1 is equal to 10 sec (not like descripted on the webif) because the use of 9 digit and not 10.
I changed only
OFFSET=echo -n "\$5" | sed 's/[^0-9-]/0/g'and add 2 logging lines
Jun 14 16:11:10 root: FreeRADIUS:Server - Client EPOCHTIME: 137121900
Jun 14 16:11:10 root: FreeRADIUS:Server EPOCHTIME: 137121905 ClientOffSet:-5 oder -5regards Max
-
Hi,
(…)
I found out that the Offset 1 is equal to 10 sec (not like descripted on the webif) because the use of 9 digit and not 10.
(...)I think you are wrong:
3. Subtract both values, multiply the result with 10 and enter the value in this field.
If your result is 2 then you need to multiply with 10 (2*10=20) and then you get the seconds.
But you are right, the script is not working. adding "+" or "-" in the freeradius users file causes problems.
At the moment I do not have an idea how to solve the problem with negatgive offset.
Perhaps starting with a negative offset of -11h as default value so that the user needs to add +11h to get the actual default offset of 0.The script is based on this:
http://motp.sourceforge.net/–-- edit ----
Ok, I changed the script to start per default with an offset of -12h. If someone is in a timezone which is -12h then the GUI value will be 0.
If someone is on timezone 0h then the GUI value must be 720.You can try with the two config files.
PS: You need to re-enable m-OTP on settings first after adding the new files so that otpverify.sh will be rubuild.
-
Hmpf - again new files. Please try these ;-)
-
Hi Nachtfalke,
i think you misunderstood me; it works with my 'patch'
i have to set offset to -5 because of 50 sec time diff (not -50 like suggest in on the webIF)see motp.sourceforge.net
Enter "date +%s" on the server to display the current time in epoch notation. Write down the first 9 digits of the output.
Subtract both values. The result is the offset in 10s of seconds, i.e. an hour would be 360, two hours 720, etc.
The offset has to be configured in the "users" file of the RADIUS server for the specific user (Offset-Attribute).sorry for my english, my german is better….
I have some idea to add more security to the radius otp: motp+yourpassword (without plus-:) would be great to have (like professional token have).
regards max
-
Hi max,
I talked to the developer of the motp script. He told me that almost nobody uses offset because most devices change their timezone automatically. Further he agreed with me that the script wasn't tested with negative offset values.
Like you told me in some older posts it looks like it is enough to change the "sed" command. I did this in this comment and it should now be available for everyone:
https://github.com/pfsense/pfsense-packages/commit/355ebce27aeb941f949f26f9c70d08150f37a7dbYour suggestion about "more" security:
The "youpassword" part is the PIN. A different PIN on the mobile device will generate a different OTP. So there is no difference between professional tokes and this. The only difference is that freeradius server does not offer a possibility for the user to change its PIN on his own.If you are using a mysql database as user store - instead of the users file - then you can code a php or HTML page which allows a user to change its PIN or his own.
But of course - if you have any suggestions and patches - please commit them. Every improvement is appreciated :)
-
Hi Nachtfalke,
thank you very much for add this in the package.
My suggestion was to extend the 'password' so it is not possible to know how long it is. I idea was to use the password field and if there is a password and otp configured use both.
If it is not possible don't worry
regards max
-
I know what you mean. I thought about that in the past but I didn't found a way to do so. The problem for me was that the variables/passwords are passing so many scripts and files and I didn't know how to realize that. This is probably more a problem of my poor coding skills than something else ;-)
Another "limitation" is that most mobile OTP generators just use the first 6 characters as password. FreeRADIUS allows to select you a higher range of used characters but then you must have a possibility on the client OTP generator to change this.
freeradius –> settings --> Token Password length
-
Hi nachtfalke,
i made some extension so i am able to handle the combination of mOtp+Userpassword. (without + :-)
It works with a cleartext + md5 password.If you want to give it a try…
Be careful you have to set the OTP length from 1-6 to only 6!!(Descript in Webif, Maybe the default setting have to adapt to 6 only)regards
-
file seems to be corrupted. 43kb is to small when including the complete freeradius.inc.
Please pay attention:
the "OTP length from 1-6" does not mean you can use 1 or 2 or 6 characters it means it uses the first until the 6th character.
if you type 10-12 it uses the 10th till 12th character of the hash which was build. -
Hi Nachtfalke,
there are 3 files in a zip container!Oh i see the zip is corrupt, sorry
I know that 1-6 means from 1 digit to 6 digits.
It make no sense that you can choose the start point, all mobile otp solution i know start with the first digit, only the lenght of the OTP password is changeable. It could be dangerious if you set the start point higher than the lenght of your hash.
But if it is a no go i change this behavor back.regards
max
freeradius.inc.txt
freeradius.xml.txt
freeradiussettings.xml.txt -
Hi Nachtfalke,
there are 3 files in a zip container!Oh i see the zip is corrupt, sorry
I know that 1-6 means from 1 digit to 6 digits.
It make no sense that you can choose the start point, all mobile otp solution i know start with the first digit, only the lenght of the OTP password is changeable. It could be dangerious if you set the start point higher than the lenght of your hash.
But if it is a no go i change this behavor back.regards
max
It is not a "no go" it just adds flexibility. If someone writes an own OTP generator which add the ability to chose different digits then the GUI is able to do so. And the default behaviour shows "1-6" so no need to change anything for the first time user.
I will try if I find some time on the weekend to check the files you added. :)
-
Hi Nachtfalke
I also think abought the "OTP Lifetime "
If you insert 18 (3min) than the server calculate every otp from currenttime - 180 sec to currenttime +180sec that are 36 OTP Passwords.This timeframe is fixed set in the original script (..do # 3 minutes before and after..) so it's much better in pfsense; able to set the range.
But going into the future is senseless, for both version.
Client has the same time as the server and users need time to insert the OTP so the otpverify.sh script is always in the future. (Ok for some weired situation like timedrift calc one otp in the future would be ok)
Also build in my version…but with no future :-)
regards max
-
Hi Nachtfalke,
did your try my mod ?
Are there any inputs/whishes from your side, or do you deny completly this mod.regards max
-
I did not try your modification but I do not completely agree with your modifications.
You say, that tokens build in the future are useless. I do not think so because the token generated depends on the time when the token is generated. So if the mOTP client on the client is running some seconds in the future then the server must accept this time difference. Of course the time on the server counts forward but there could be still some difference. Further it is not sure that the server and the client will always count the time equal. Some end could be faster than the other and it could came to a difference over some weeks or months. So I would not "delete" this option from the code. Further you can lower the timespan of a OTP so that the difference is 10s before and after. Thats not much and no security issue.
Changing the range where and when the digits start and how much digits needed is no good choice in my opinion. Of course all mOTP clients on the http://motp.sourceforge.net/ website only use the first 6 digits but the pfsense GUI is able to make it more flexible and dynamically for other mOTP solutions. So why delete an option which nobody hurts but offers more possibilities.
I did not dig deep into your code - because I am not good at coding - but this should be something which needs to be implemented into your code when using a fixed part of password and the OTP or a hint in the description that it only works when using digits 1-6.So what I would like to have in the code is the "fixed" and the "OTP" part in a password. Even if it makes not so much sense, because the "fixed" part is still there - with the 4 digi PIN - which needs to be entered on the mOTP client to start generating OTPs. I know that when using the RSA securID tokes you often use a fixed part in the password but this is because you cannot enter a PIN on the token itself to start generating OTP - it always generates passwords.
And on the coding page - For me the new variable name you added in the code for the fixed part of the password is not "optimal" - I think. But this is absolutly cosmetic and probably absolutly unimportant for the mOTP solution in general.
So even if I am the developer and maintainer of the freeradius2 package I am happy that other people add their ideas. So you modification is absolutly welcome but I think that there are some things which should be added and other which should not be lost to make the package as compatible and flexible as possible.
So I think if we could find an arrangement for your code you could add it here:
https://github.com/pfsenseand then someone or I could merge it.
Thank you for your feedback and your contribution! I really appreciate it! :)