8 Replies Latest reply: Jan 8, 2013 10:51 AM by EdStevens RSS

    allowed characters in 11g password

    TPD-Opitz
      Hello,

      where do I find a list or a description of allowed characters for a 10g password?

      bye
      TPD
        • 1. Re: allowed characters in 11g password
          Herald ten Dam
          Hi,

          it is somewhat described in the SQL manual for the Create User statement: http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8003.htm
          See the "BY password" paragraph.

          Herald ten Dam
          http://htendam.wordpress.com
          • 2. Re: allowed characters in 11g password
            EdStevens
            TPD Opitz-Consulting com wrote:
            Hello,

            where do I find a list or a description of allowed characters for a 10g password?

            bye
            TPD
            Just beware that there are characters that oracle will allow in a password, but can cause issues in the larger context.
            Consider this typical connection:
            sqlplus scott/tiger@orcl
            Notice that the "@" is used as a delimiter to indicate the beginning of the net service name. Now, suppose you have an "@" in your password:
            sqlplus scott/p@ssword@orcl
            When sqlplus parses the command line options that are passed to it ("scott/p@ssword@orcl") it is still going to take the first occurrence of "@" as a delimiter. So it will think the password is simply "p", and will pass on to tns the connect string of "ssword@orcl". Then tns will go looking to resolve a net service name of "ssword@orcl".

            Similar nasties can happen in unix scripts if your password has a "$", indicating to the shell processor that an environment variable needs to be substituted.
            • 3. Re: allowed characters in 11g password
              TPD-Opitz
              EdStevens wrote:
              Notice that the "@" is used as a delimiter to indicate the beginning of the net service name. Now, suppose you have an "@" in your password:
              sqlplus scott/p@ssword@orcl
              I've learned from the docs that this will be valid:
              sqlplus scott/"p@ssword"@orcl
              bye
              TPD
              • 4. Re: allowed characters in 11g password
                EdStevens
                TPD Opitz-Consulting com wrote:
                EdStevens wrote:
                Notice that the "@" is used as a delimiter to indicate the beginning of the net service name. Now, suppose you have an "@" in your password:
                sqlplus scott/p@ssword@orcl
                I've learned from the docs that this will be valid:
                sqlplus scott/"p@ssword"@orcl
                bye
                TPD
                Yes, it would, but that would then require that particular user to always enclose his password, whereas other users don't. Much like enclosing column and table names so that you can force mixed-case naming. It's possible but therein lies the road to perdition. How long will you beat your head against the wall debugging a ora-12154 before you think to ask the user to show you his password in clear text?


                I have my password complexity routine coded to specifically disallow that character, just to avoid 'issues'.
                • 5. Re: allowed characters in 11g password
                  TPD-Opitz
                  EdStevens wrote:
                  Yes, it would, but that would then require that particular user to always enclose his password, whereas other users don't. Much like enclosing column and table names so that you can force mixed-case naming. It's possible but therein lies the road to perdition. How long will you beat your head against the wall debugging a ora-12154 before you think to ask the user to show you his password in clear text?
                  the bsystem that I have in mind does not allows (or at lease expect) "normal" useres to connect via SQLplus. There is a Forms application providing a login dialog. I expect this dialog to convert passwords to quoted identifiers .
                  I have my password complexity routine coded to specifically disallow that character, just to avoid 'issues'.
                  On the other hand we have a company rule for complex passwords. I think Database should not be the restriction here.

                  bye
                  TPD
                  • 6. Re: allowed characters in 11g password
                    EdStevens
                    TPD Opitz-Consulting com wrote:
                    EdStevens wrote:
                    Yes, it would, but that would then require that particular user to always enclose his password, whereas other users don't. Much like enclosing column and table names so that you can force mixed-case naming. It's possible but therein lies the road to perdition. How long will you beat your head against the wall debugging a ora-12154 before you think to ask the user to show you his password in clear text?
                    the bsystem that I have in mind does not allows (or at lease expect) "normal" useres to connect via SQLplus. There is a Forms application providing a login dialog. I expect this dialog to convert passwords to quoted identifiers .
                    I have my password complexity routine coded to specifically disallow that character, just to avoid 'issues'.
                    On the other hand we have a company rule for complex passwords.
                    Great. and exactly how is that policy enforced?
                    I think Database should not be the restriction here.
                    The database is the only entity that can enforce passwords for database accounts. If you have a company policy, the database's complex password function is how that policy is enforced. Without the complex password function, company policies are just pieces of paper.
                    >
                    bye
                    TPD
                    • 7. Re: allowed characters in 11g password
                      TPD-Opitz
                      EdStevens wrote:
                      The database is the only entity that can enforce passwords for database accounts. If you have a company policy, the database's complex password function is how that policy is enforced. Without the complex password function, company policies are just pieces of paper.
                      The point ist that users in general authenticate against an AD. There is only one Application (this fine forms app) that authenticates against an oracle database.

                      So you honestly suggest to restrict users password complexity because it's some what tricky to implement in the form app?

                      bye
                      TPD
                      • 8. Re: allowed characters in 11g password
                        EdStevens
                        TPD Opitz-Consulting com wrote:
                        EdStevens wrote:
                        The database is the only entity that can enforce passwords for database accounts. If you have a company policy, the database's complex password function is how that policy is enforced. Without the complex password function, company policies are just pieces of paper.
                        The point ist that users in general authenticate against an AD. There is only one Application (this fine forms app) that authenticates against an oracle database.
                        If your users are authenticating against AD, then that's where their authentication lies, and that's where enforcement of rules lies.
                        So you honestly suggest to restrict users password complexity because it's some what tricky to implement in the form app?
                        No, I suggest restricting users password complexity (and this was assuming db authenticated user accounts) because that is the only place where you can enforce any policies you have. That is irrespective of what those policies are, including whether or not you allow or dissallow any particular characters.

                        I suggest not using passwords that require enclosure in quotes for the same reason I suggest not creating database object names (tables, columns, etc) that require enclosure in quotes. It simply "goes against the grain" in Oracle and then requires to you always do it for the names that have been created that way. Forms or not.

                        Just because something CAN be done doesn't mean it SHOULD be done.

                        >
                        bye
                        TPD