That open should fail, as you're trying to go to the parent directory of the root node. And the fundamental point is, the root node for serving documents is not the file system's root node, and there's no URL that would allow access to it (assuming a non-insane configuration). So put your password file at '/etc/secret/password.txt' or any other location outside the web server's document directory structure, and it will not be accessible by browsing, even if the path and file name is known.
There is no rule that requires any file to be directly accessible by URL. What can be accessed is controlled by the server configuration.
You can add another layer of protection by saving the passwords in a way that makes them nearly useless in case somebody manages to steal your password DB.
If you don't save the passwords as clear-text but i.e. as salted message digest of the clear-text password, then an attacker might steal your password file but will have problems to exploit this knowledge directly.
When the customer provides a (clear-text) password, your CGI will 'salt' it ('salt'-value from your DB), re-compute the message digest, and compare it to the value stored in your password-DB. If it matches, it is very likely, that the password is correct (simplified description). The 'salt' makes it harder for an attacker to pre-compute password lookup tables. The paranoid also checks for weak passwords.
Since you do not store the clear-text password, nobody can steal it. One consequence is that you cannot provide a password to a customer who has forgotten it - because you don't have it.
It's not perfect, but adds a little more protection for your password DB.
CPAN provides a lot of suitable modules, Authen::Passphrase::MD5Crypt is only one of them. The principle is described here.