1st a typical jumpcloud radius-server cfg for a fortiOS device
reference one of my many previous blog on this
http://socpuppet.blogspot.com/2017/03/using-jump-cloud-radius-for-fortimail.html
/* A FortiOS cfg example
config user radius
edit "jcradius"
set server "18.204.0.31"
set secret ENC H0YE6EqYG0W9AB1uXPbAsKwQIAS9IxYI7T4v3VOjBj9f89U0RfmDfbD6U47dU6DD+3YidfbkGvtwzFYhCFsSQY8DodYhtsFiyKBBN1t6unIGH+ZlgB/MQaFOx/ncbNnyTk6D4RObIKj3BSGd9DbEr2jm4Vv+w6/nXa/Y64pCq6cZWpdQfRr4EylK+A5zD4r/XiCnetQ==
set radius-port 1812
next
end
Okay, that's easy and we can test via the "diag test authserver radius-direct" cmd from the cli. Here's where it gets funky. I continue to authenticate with the same OTP and over a period that was almost 2mins. Finally, the previous OTP was not accepted for my usernamed "mfa" as you can see with the "Access-Reject" message
Even the user-portal login exhibits the same behavior upon my testing.
And OTP 125738 for "mfa" user has long expired ( see OTP value #861102 ) , but I can still login with the now expired OTP 60secs later and after a new OTP has been generated.
So jumpcloud has granted the OTP upto the next-plus-next OTP cycle.
e.g
OTP . 123 456--30sec ---> expired,
new OTP 667 788----30secs later expired,
new OTP 788 928--30sec expired,
and now previous OTP 123 456 is now not honor some 60seconds plus the original expiration.
So this violates two functions and rules within OTP usage for MFA authentication
1: A OTP is good for 30secs ( +- a few secs )
2: A QTP becomes invalid after a successful login ( prevent reuse or the continual use.....the OT in OTP is suppose to mean "One Time" ! )
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
No comments:
Post a Comment