Please more info, examples, etc ...

I could not reproduce.

Hi Roman,

try

passwd root

give by example:

BillyBoy34

again

BillyBoy34

logoff as root

login with root

give

BillyBoy51

-((

I testit also on my old test Maschine with nexenta rc3. The same Problem.

Regards Stephan

http://nexenta.org/boards/1/topics/957 Roman Strashkin

Please more info, examples, etc ...

I could not reproduce.

I succeeded. Really bug.

Thanks. We will fix it.

Hi - this bug is also in Commercial NexentaStor 3.0.3. I suggest you to fix that quite soon...

I have opened a bug and since + we also have a commercial Edition request for bug report: http://nexenta.org/issues/241

I think that perhaps only the first 8 characters of the password are significant.

Admittedly, this is unfortunate, and more research is needed.

• Garrett

I thought the default crypto was changed as result of my ticket: #211 ( http://www.nexenta.org/issues/211 )

The default unix crypt which does indeed only uses the first 8 chars with a very weak DES cipher. You can check this very easily by settings your password to: 1234567890 Afterwards you can login with 12345678 but not with 1234567.

Therefor it was recommended to use a stronger algorithm specially considering the target audience and hardware of Nexenta. (nobody should care about using blowfish or sha512 on the type of hardware recommended for usage of nexentastor)

I also thought it was changed/fixed (as indicated in the ticket), but my current /etc/security/policy file on Nexentastor 3.0.4 again uses the default _ unix _ cipher. (The word unix and the underscores should not contain spaces but it's impossible to type it correctly due to the wiki formatting)

edit Yeah I found the edit button in this ticket tracker... still i wish this was a normal trac instance...

For those that don't follow the link to the ticket above, it's an easy fix to make on your own box. There is a patch in the ticket, but all you need to do is change two entries in /etc/security/policy.conf to the following:

 CRYPT_ALGORITHMS_DEPRECATE=__unix__
    CRYPT_DEFAULT=2a

Then the next time you change any of your passwords they are saved more securely and use more then 8 characters.

-apnar

Hi

Thanks for your examination. I have read and test this. http://docs.sun.com/app/docs/doc/817-0365/6mg5vpmc1?a=view

"Using the Blowfish Algorithm for Password Encryption"

I tried to configure blowfish "2a" in /etc/security/policy.conf and reboot.

@#CRYPTALGORITHMSDEPRECATE=unix

CRYPT_DEFAULT=2a

After that I set a new password for root and my sudo-user. It works. Also for ssh-login. The problem is at the moment patched.

BUT NOT for Napp-it user !! The problem for user "admin" in napp-it gui is not fixed with the change to blowfish!

GUI "napp-it Web-Interface" from --> napp-it -> setup -> set new admin password: && set new operator password: Here I have the same problem. Login as "admin" with wrong password. !!

Thanks a lot. Please inform the people of napp-it.org Stephan

http://nexenta.org/boards/1/topics/957 Apnar .

For those that don't follow the link to the ticket above, it's an easy fix to make on your own box. There is a patch in the ticket, but all you need to do is change two entries in /etc/security/policy.conf to the following:

 CRYPT_ALGORITHMS_DEPRECATE=__unix__
    CRYPT_DEFAULT=2a

Then the next time you change any of your passwords they are saved more securely and use more then 8 characters.

-apnar

Yes you can 'fix' it as described above.

$ vi /tmp/policy.patch
... copy-paste-patch-as-described-in-the-ticket ..
$ cd /etc/security
$ patch < /etc/policy.patch

Or change the couple of lines yourself in /etc/security/policy.conf :-)

Guess the Nexenta people should look at what changed if the change they made to sunwcsr disappeared.

It also looks like it's impossible to reopen the ticket in this tracker. Since this is a regression... But I will at least comment on the ticket with a backlink to this forum topic :)

Stephan Hesse wrote:

Hi

After that I set a new password for root and my sudo-user. It works. Also for ssh-login. The problem is at the moment patched.

BUT NOT for Napp-it user !! The problem for user "admin" in napp-it gui is not fixed with the change to blowfish!

GUI "napp-it Web-Interface" from --> napp-it -> setup -> set new admin password: && set new operator password: Here I have the same problem. Login as "admin" with wrong password. !!

Thanks a lot. Please inform the people of napp-it.org Stephan

Thanks for the info
There is a password bug in current napp-it
allowing login with wrong passwords having the same characters at the beginning
i will solve the problem in next nightly 0.317

gea
www.napp-it.org

hello all

napp-it 0.317 is out.

-max password length: 16 char
-after updating, you have to reenter napp-it passwords

gea

I'm quite unhappy to see the bug not been fixed in the officially released NexentaStor 3.0.4 starting this week. Quite surprising after the quite long time gap for QA since last NexentaStor EE 3.0.3. :-(

I've re-pinged Nexenta support for our support ticket since I have waited for 3.0.4 release to check back. My ticket at Nexenta is still open, I'll report back if I have some useful news.

NexentaStor should indeed have the bug fix. Its possible that upgrading won't apply the fix for you automatically, I'll need to research it. (But you can change the defaults yourself as detailed above.)

As for napp-it, that's not something Nexenta provides any official support for. If you're complaining about that, I'm not sure we can help you.

Hi

I do know that neither NCP, nor NexentaStor are commercially supported by Nexenta - I'm absolutely conscious. I did only update the thread in order to update users of NCP whether or not there was a fix in NexentaStor,. Since NCP is NexentaStor's upstream I reported it here - with the intent no work being duplicated. :-)

The bug is indeed not fixed in a fresh install of 3.0.4 CE (since I can't touch the 3.0.3 EE box for testing), I did a fresh install in a VM to verify. Garrett, there is already a ticket open on Nexenta support. This thread's contuinuation was to keep NCP users updated, no more no less.

(take the following with a "pinch of humour" as literally translated from my native language) There is just a dilemma with the /etc/security/policy.conf fix: It's not a Nexenta-provided one - and since works outside NMC is not supported/allowed outside this console in the appliance OS, I wanted to wait for a delivered/supported fix. That is the dilemma of a supported version ... you have someone to ask when problem occur and blame 'em for errors, but you are not allowd to hack the things without losing support ;-)

Since the ticket is still open at Nexenta Support, I'd prefer to keep efforts focussed there and then update on NCP bugreport as soon as there is a bugfix for the upstream NCP.

Update: If the fix gets into NexentaStor, since I couldn't find anything that would get messed up by this small change, I hope to see it also in NCP. Even Sun documented that cryp_unix couldn't be considered safe enough nowadays but remained there for legacy compatibility... http://docs.sun.com/app/docs/doc/816-5175/crypt-unix-5?l=en&n=1&a=view