|
|
Post by vincent0607 on Feb 1, 2024 9:39:43 GMT
Follow up redfish spec 1.19 for 13.5.3 section 'Atomic password changes'
We would like to clarify following statement about term 'session hijacking' meaning from spec
This functionality can be used to protect the service from session hijacking
from my understnading , not sure which one as below is correct ?
1. use this "change passord" action mechanism, can prevent from session hijacking, means nobady can steal the seesion token
or
2. once unexpected people take illegally the session token for adminstrator permission, although he can do almost any things in redfish API request, but he can not change account passowrd due to 'Password changes' action mechnaism protection (if PasswordChangeRequired set true)
or it should be other meaning you think correctly ?
thanks
|
|
|
|
Post by mraineri on Feb 1, 2024 14:18:57 GMT
It's the second; if someone somehow obtained a valid session token for an admin, they could change the admin's password with a PATCH operation and not need to know their current password. In this case, the attacker has effectively taken over system and the real administrator cannot log back into the service, which makes recovery impossible without other means of intervention.
At the very least, any admin can close open sessions if they believe a session token has been leaked. But you're correct; if someone has somehow obtained a valid session token for an admin, they can do other types of operations. But at least the admin's password is still valid and they can take recovery actions.
|
|
|
|
Post by vincent0607 on Feb 2, 2024 6:24:15 GMT
Because Redfish use HTTPS and HTTP header is also encrypted (session token put in HTTP request header),
it is almost impossible that hacker can fetch "valid session token" by listening network packet? this means redfish still is secure and safe right ?
-----
Unless the owner accidentally leaks the session token to others, but this is the owner's own problem, right ?
|
|
|
|
Post by mraineri on Feb 2, 2024 15:08:14 GMT
Yes, this would have to be by some other means; sniffing network packets is very unlikely.
One of the scenarios raised was specific to browser-based clients that might keep a session open. If a terminal with the browser is left unlocked, someone could walk up and perform those operation. It's extra protection like how when you log into a website and want to edit the password for your account, the website will prompt you for your current password too to ensure you really are the account owner.
Yes, you're right that this really is the admin's problem, but folks saw value in this as a means to help give admins a bit of a safety net for situations like this.
|
|
|
|
Post by vincent0607 on Feb 6, 2024 13:28:06 GMT
thanks for the explict explination
about the implementation, the redfish spec mention as below in "atomic password changes" section
If the RequireChangePasswordAction property in the AccountService resource contains true , services
shall reject modifications to the Password property in ManagerAccount resources in PATCH or PUT
operations.
for more detail about "reject modifications", do you have a suggestion that should return which message from Base message registry ? thanks
|
|
|
|
Post by mraineri on Feb 6, 2024 13:45:26 GMT
"PropertyNotWritable" would make sense to me since in that state the property effectively becomes read-only.
|
|
|
|
Post by vincent0607 on Feb 7, 2024 0:48:12 GMT
thanks!
on the other hand, if RequireChangePasswordAction = false,
does ChangePassword Action allow to be operated in AccountManager resource ?
if disallow, should the service return which message from Base message registry ?
|
|
|
|
Post by mraineri on Feb 7, 2024 14:05:20 GMT
Yes, you can still use that action to change the password even if RequireChangePasswordAction is false. "RequireChangePasswordAction" only affects the ability to PATCH the Password property directly.
|
|
