I believe in using strong passwords but the passwords generated by randpass 32 esc are not working for so many applications and tasks that I ask you to seriously consider using alnum.

Here is the randpass generated by my latest boa 2.0.7 octopus instance (using percona as db): )2c,~Ng/L%K]4iYG54klCtFq8dI_X

Both of the ssh2 / sftp I use to connect to the server as the o3.ftp user will not accept this password.

Additionally, a remote import I tried will not accept this password. - that is the boa octopus remote import that I tried today failed because it would not accept the password.

I feel strongly that certain characters that are generated by randpass 32 esc - for example the / the % the _ (all of which can be seen in the above boa generated randpass 32 esc) as well as the ; the . and the , should not be used as plain text passwords. There are going to be too many errors with third party applications, database errors and even hostmaster or provision tasks like the remore_import.

Would you please at least test this further to make sure that all characters generated by the randpass 32 esc are usable in common applications and all provision / hostmaster tasks, etc? Thank you.

Files: 
CommentFileSizeAuthor
#6 fast1.pass_.txt32 bytesEdNet
#6 fast3.pass_.txt30 bytesEdNet

Comments

Status:Active» Closed (works as designed)

We have tested this and it doesn't affect Aegir operations. Furthermore, it is not default. Furthermore, even if you enable this feature with _STRONG_PASSWORDS=YES, it always uses randpass 32 alnum for all SSH/FTP accounts. The randpass 32 esc is used only for internal system passwords.

[EDIT]: Please note that Aegir can use strong passwords generated with randpass 32 esc, because it automatically converts them to safe format with urlencode() and urldecode().

Category:support» bug
Status:Closed (won't fix)» Closed (works as designed)

Today I tried a remote import from a BOA 2.0.7 stable with percona to a BOA 2.0.7 stable using mariaDB and it failed because it did not accept the o1 password. I was following your tutorial at http://drupalcode.org/project/octopus.git/blob/HEAD:/docs/REMOTE.txt#l109
and right after the

rsync -avzu --ignore-errors -e ssh o1@source-host:/data/disk/o1/distro/003/platform /data/disk/o1/distro/003/

command to transfer the files it asked for my o1 password, and it failed to accept the valid password:

rgkMTk&HYYI5*bWA^Xar?FMoc0Qf

Category:support» bug

- perhaps the ^ the ? or the & and the < are simply not going to work for some applications if they are in plain text. Additionally the ^ for me is strange because it does not even appear on the screen or page or command terminal until I type another character after it. That could be a problem.

Status:Closed (won't fix)» Closed (works as designed)

Then please don't use strong passwords. Supporting the remote import feature is not important enough to us. It is confusing and slow method and we plan to replace it with command line tools already, as mentioned in the other thread.

Category:bug» support
Status:Closed (works as designed)» Closed (won't fix)

Changing to correct status.

Category:bug» support
Status:Closed (works as designed)» Closed (won't fix)
StatusFileSize
new30 bytes
new32 bytes

they look like randpass 32 esc passwords to me

Status:Closed (works as designed)» Closed (won't fix)

OK

Yes, because fast1 is a system only account, without any shell by default, and it should use randpass 32 esc, while randpass 32 alnum is used for fast1.ftp and all other extra FTP/lshell accounts.

Just wanted to mention one more thing. The character ^ is a funny one, and you might want to not allow it (if filtering it out is even possible), because it is, in effect a dual-purpose character - it is used as an accent if followed by e or I or o as in ê î etc .. so that If I want to type ^e or ^I I have to literally type ^followed by a space bar entry followed by the e or the I or the o, otherwise I get the accented character. If you think a person might ever need to type a randpass 32 esc password into the command line, then the ^might be a very good character to leave out because of its dual use nature. Same with ¨ , the ~ and any character that can also be used as an accent mark. Something to consider carefully. Thank you.

Again, passwords generated with randpass 32 esc are used only internally and further encoded/decoded on the fly if needed, and any problematic characters have been already filtered out. These passwords are *not* intended to be used as manually entered or for any service like FTPS/SSH.

Issue summary:View changes

modified pass to prevent problems