I have no requirements for this field by default in my case.
1) If password field accept password like 8 empty spaces in a row, is it usually considered like a bug?
2) If no validating for field length(it accept password of any length) is considered like a bug?
If this two points is bugs, they can be counted as functional bug?
Since you don't have guidelines, you would have trouble justifying the behavior of the password field as a bug.
That said, I'd suggest you raise a bug and classify it as a security flaw. You can cite the OWASP security standards password section to justify your case, even if the application isn't a web app: any software that needs a password by definition holds some level of sensitive information.
If you don't have specific requirements you should design test cases based on best practices, best user experience and security.
It's not a bug, because it does not behave differently from expectations (you don't have any) but allowing to create password that is weak may lead to account hijacking and information leakage which is an issue. You have to think of a password policy which might be worth to implement.
It also is not a bug. It depends on how these passwords are stored in DB, which algorithms are used for hashing passwords and so on. Password length validation on front-end should only prevent from damaging the back-end(or triggering internal server error) by using too long string (in case when in DB it was set to e.g 64 chars) or any related cases. This should also be based on password policy.
I would say, based on description above, that these are non-functional issues, specifically security issues
