This discussion is archived
8 Replies Latest reply: Jan 8, 2013 8:51 AM by EdStevens RSS

allowed characters in 11g password

TPD-Opitz-Consulting-com Expert
Currently Being Moderated
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 Expert
    Currently Being Moderated
    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 Guru
    Currently Being Moderated
    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-Consulting-com Expert
    Currently Being Moderated
    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 Guru
    Currently Being Moderated
    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-Consulting-com Expert
    Currently Being Moderated
    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 Guru
    Currently Being Moderated
    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-Consulting-com Expert
    Currently Being Moderated
    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 Guru
    Currently Being Moderated
    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

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points