Moving a non-support topic to general.
First time I see someone introduced complexity rules for BIOS password. Why framework thinks that I need “a symbol” or “a number” in the BIOS password? Framework could you please read decade old research and US/UK/EU governments recommendations on password complexity rules, and get rid of this in the next BIOS update.
(screenshot, from the frame work 13 laptop AMD edition)
unfortunately this requirement also kind of broke my neck a little while ago when trying to reconstruct my forgotton bios password (other thread) too bad. i couldnt find any documentation about what these exact requirements were and I was completely oblivious and couldnt come up with any combination of my usual base password i tend to use for such situation and no variation i tried worked. meanwhile, i have reset the bios password with special help from f.w. support help that was not documented (yet?) and now I have set a bios password again and i am kind of sure by now that i actually have now the very same password variation that i couldnt come up with to begin with when trying to access the bios back then when following those rules of complexity given.
The bios complexity rules are super annoying, but what completely got me is that TEN character limit. This is a super weird limitation and I don’t really use any passwords that short…
This really needs to be the other way around: make the length limit sensible – like, 256, I don’t know, or, at least, something like 60 (the longest password I currently use is close to 50, but there needs to be some buffer for the future!) – and remove these complexity rules.
Framework is a U.S. company, so I’ll quote from NIST Digital Identity Guidelines (Section 5.1.1.2):
Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length.
Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length.
Verifiers SHOULD offer guidance to the subscriber, such as a password-strength meter [Meters], to assist the user in choosing a strong memorized secret.
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.
This is the weirdest part: Why would anyone on any system impose a password limit? This makes no sense to me. Every time I encounter such a limitation, it makes me think the system is actually saving the pw as a plain string in a database or so. at least that would explain the stupid limit…
instead, a password should be hashed countless times (e.g. pbkdf2, argon2), making it really expensive to reconstruct a single password from the resulting hash (+salt). Plus it makes the character limitation a thing of the past, as the hashed and salted pw should always result in a string of identical length.
Yes, the 10 symbols limit is super bizarre, I think this is the limit of drawing stars in the control, they have space for 10 symbols, I’ve automatically typed my 20+ long password, not even realizing it was truncated. Framework, please fix both issues, no need for complexity rules or length limit (OK you can have the limit if you want but around 1024 symbols )
What annoys me even more is the other day I got a message saying my BIOS password has expired and needs to be changed.
Is there a setting I have missed to disable this?
Just hit this issue myself and am frustrated to say the least. It’s like the BIOS enforces poor security. Frequent password changes make passwords easy to forget and there’s no passoword manager autofill in the BIOS, so I guess I’ll just write the password on a piece of paper. Not to mention the flawed complexity rules and length limit already mentioned above. And to top it all off, the BIOS remembers historical passwords for who knows how far back, so not only can you not reuse a password you’ve ever used before, you also have a nice password list saved in the flash for anyone skilled enough to extract and (hopefully) crack (hopefully because, with the length limit, it could also just be plaintext).
All this nonsense is making me reluctant to even set a BIOS password because of all the hoops I have to jump through. Is that the goal here?
The password history is the worst. I set up the machine, had a couple of issues, within an hour I’d reset BIOS to defaults. Tried to set the same password again, no dice. Super mad about that. If you’re going to enforce a 10 character limit you don’t get to enforce password history.
My understanding is that Framework has not developed the BIOS from scratch. Instead, it has been licenced (?) and adapted - feel free to correct me if wrong. Perhaps this came with the base version and they haven’t made changes to the password policy as not a major priority.
Regardless, the whole password situation is utter nonsense and should ultimately be addressed, hopefully soon.
This does seem like a low effort/high impact kind of issue so i hope they get that into the next bios release.
Oh my god. Hasn’t happened to me yet, but this is absolutely insane.
I’ll quote from the NIST Guidelines again:
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).
I think you are right, and my understanding is that they actually licensed the source code, so they are able to make any changes they want.
Fingers crossed. I hope they understand that it is actually a high impact issue. Once the passwords start expiring for everyone, people start adding some random bs and then forgetting them…
Does it say InsydeH2O or Insyde at the top of your BIOS screen?
Last I read, the BIOS firmware is licensed from Insyde Software - Wikipedia. I don’t know if it’s different on newer boards.
~edit~
Looks like the 13th gen intel and AMD boards are still using Insyde.
https://nitter.net/insydesw/status/1639393614148296705
Insyde Software @insydesw Mar 24
Congratulations to @FrameworkPuter for their exciting launch event yesterday, including the unveiling of the latest InsydeH2O-powered Framework 13 laptops featuring the AMD Ryzen 7000 series and 13th Gen Intel Core CPUs!
YES
But seriously, never have more truer words been spoken/typed/copied&pasted.
Agreed, this is absolutely ridiculous and bad practice. Combined with the 10 character max length this stuff is ass-backwards.
Add my name to the list of villagers hoisting torches and pitchforks against the password policies embedded in the Framework 13 (AMD 3.03) BIOS.
While I’m in agreement with all the above posters’ arguments, I’m of the opinion that since this is a sold product—as opposed to rented, leased or issued by some entity—with the transfer of funds, ownership—along with its responsibilities in addition to its rights—has passed to me. Therefore, FW has no right or basis to dictate—and enforce—device security policy to me. They meet the definition of tyrant for that.
In the real world where I live, I use a BIOS password the render the device worthless to common garden-variety burglars. Not even in my worst dreams are government agents (or worse, foreign government agents) trying in break into my laptop when I’m not home. (To mitigate that, I use full disk encryption anyway.) I just want the boot password to effectively brick the device should some druggie burglar come a calling.
But perhaps more importantly, I don’t need or want a memory and typing test before coffee in the morning.
I have been happy, nay, delighted in every way with my FW13 and the company. Which only makes this mistake all the more glaring. And given what little I know of the company by their propaganda, erm… I mean, marketing materials… it seems to go against both the principles and the principals of the company.
So outraged peasants arise against the tyranny of the enforced 10 character maximum and 30-day forced rotation!
Here is an experience with the AMD 13-inch unit I got:
I was very excited to get the Ryzen 7840 model until about three weeks later it demanded the BIOS Supervisor password change, not allowing the boot to proceed.
I changed the password, but in the process, the BIOS enforced the uniqueness of about the last ten passwords and the complexity requirements. Which, is mind-blowing, undocumented, and unwelcome. Security experts advise against these practices.
Naturally, I thought, such a drastic and undocumented feature was easy to turn off.
Wrong.
It took SIX communications with Framework support to get somewhere. In the process they either did not care to read the question or did not want to address the question. Those exchanges included Framework’s Head of Global Customer Experience.
The final result:
Hello Vlad,
This case was reviewed with our Engineering team and we can confirm that it is not possible to remove the enforcement of the BIOS password parameters.
Regards,
Framework Support
Wowsers
The password “expiration” did not yet happen again. But I can not imagine any large-scale purchaser would be happy to manage a mess these “features” will create at a scale. Attached are some illustrative images.
Naturally, the request here is to allow disabling all of the password enforcement as a whole - at least.
On a server: any kind of request should be limited. Even if the password is not stored in plain text, if the server lets me upload a gigabyte of password data, that’s a gigabyte of data the server will need to hash and an excellent entry point to make your DDoS attack super effective. A generous limit, like 128 characters is obviously nicer than PayPal’s 20, but there has to be a limit.
In a BIOS: this is very low level code, it’s not guaranteed that memory allocation is possible nor that you can store much data in BIOS memory, there has to be a bound. Arguably, 10 characters is too low, but don’t expect 1KB (although I guess they could hash it for the storage property, but it still has to have a limit anyway).
I’ve been considering deploying frameworks in my corporate environment. We mandate bios passwords and custom secureboot keys. This issue is disqualifying until it is resolved.