and the winner of RC5-32/12/9 is!..any kind of encryption can be broken quite easily
you may boot from any Linux LiveCD and mount ROS partition to copy files from itis there a way I can get the backup from the router OS then copy it into my laptop and extract the password.
http://en.wikipedia.org/wiki/Cryptograp ... h_functionto encrypt something, we need a key. you would have to provide a password that you would have to remember.
not possible? Normis, if you don't know - let the developers do their work. M$ Windows never stores plaintext passwords, but user authentication over network IS secure, plaintext passwords are NEVER sent over the network, even encrypted. look at MSCHAPv2 - it 1) does not store plaintext password anywhere, and 2) if server doesn't know user's password, it cannot even authenticate the user (by just saying "Okay, I'll pass you with that password") - because in that protocol user must ensure that server knows his password toobut passwords in the router - we need to have access to plain text password, otherwise secure authentication
over network is not possible, i.e. bandwidth-test, winbox, webfig, etc.
Thing with Microsoft is - it is enough to know your "encrypted password" to successfully authenticate over MSCHAPv2 (there is no need to know plain text password at all), i.e., your encrypted password becomes real password. So looks kinda silly example to me.we're talking about passwords
not possible? Normis, if you don't know - let the developers do their work. M$ Windows never stores plaintext passwords, but user authentication over network IS secure, plaintext passwords are NEVER sent over the network, even encrypted. look at MSCHAPv2 - it 1) does not store plaintext password anywhere, and 2) if server doesn't know user's password, it cannot even authenticate the user (by just saying "Okay, I'll pass you with that password") - because in that protocol user must ensure that server knows his password too
Now you can move from quantity to quality (joke)!p.s. my 6000th post
Unlike many others, I think he has it bothNow you can move from quantity to quality (joke)!
I don't understand your point. You are asking us to make this, but then you are saying that people can log in with the hash. OK, hacker can't "read" the password, but the security is compromised anyway.A lot of confusion about this so I'll bottom line it. It is possible. It is NOT overly hard to do. It is considered safe.
One thing is, we want the password stored securely (I.E. hashed) and authenticate against this hash. Authentication exists by hashing the password that the user inputs, if the hash of that inputted password matches the stored hash, you have access. Otherwise you are denied access.
Storing the hash won't reveal the password to the hacker (you can relatively easly obtain the hashed passwords Windows stores. Unfortunately, they are vulnerable to rainbow attacks but that's another story).
agree, I need a coffee... =)Thing with Microsoft is - it is enough to know your "encrypted password" to successfully authenticate over MSCHAPv2 (there is no need to know plain text password at all), i.e., your encrypted password becomes real password. So looks kinda silly example to me.
yes, in case of network login. but it's completely impossible when using local loginYou are asking us to make this, but then you are saying that people can log in with the hash. OK, hacker can't "read" the password, but the security is compromised anyway.
you can, see chupaka post aboveNo, if you input 0FBECDE5 directly (if you use it as password instead of 1234), the hash algorithm will hash 0FBECDE5 and not 1234. This would yield, for instance, FBC3B9A2 and FBC3B9A2 does not equal 0FBECDE5.
You have the secure storing of a password on one side (by hashing it as I described), and secure authentication on the other side. Both are needed.
So you cannot log in by inputting the hash as a password because the hash you input will be hashed and transformed as I just said.
I agree, everybody must have unique long-and-hard-to-remember passwords for each of hundreds devices - then MikroTik won't even worry about your plaintext password comprimiseas we all know that using same username/password on all the routers is plain stupid anyway.
Bullshit.But to verify that hash we need plain text password on the router.
btw, if we elaborate that thought, everybody should use other vendors' equipment, not to bother MikroTik =)I agree, everybody must have unique long-and-hard-to-remember passwords for each of hundreds devices - then MikroTik won't even worry about your plaintext password comprimiseas we all know that using same username/password on all the routers is plain stupid anyway.
because API protocol does not support encryption %(Tell me again why the rb needs to store the plain text password?
So should the API not be update to take the text given, hash it, then compare that with what is stored on file?because API protocol does not support encryption %(Tell me again why the rb needs to store the plain text password?
p.s. that's not true, they can store pre-calculated not finished MD5("\x00" + PWD) value for API logins
API does not send plaintext password, it sends MD5("\x00" + password + challenge) - so the result is different every time
in spite of that, it's possible to save MD5 registers after hashing ("\x00" + password) - and then server will be able to construct MD5("\x00" + password + challenge) without plaintext password
it's too late - API is on stage, nobody will rewrite all software that uses another authentication. I just say that it will be still possible to support API authentication w/o plaintext passwords on the routerThey could send
I see what you mean. But it looks like Mikrotik have too much baggage code/programs and changing their authentication scheme now will be very hard.Normis,
I think you guys completely misunderstands how password hashing works.
Simple Hashing would be:
password_hash = algorithm(password)
This has a problem in itself that one could use a lookup hash table to easily get the password.
However this can be overcome by using a salt:
X must be constant
salt = X number of random characters (printable + non-printable)
password_hash = salt + algorightm(salt+password)
To check a password that the user enters, you take the first X characters from the stored hash and just use the same function again. If the hashes match, voila, your password is correct.
If you feel this is still insecure, one could look at public/private key auth the way SSH does
by the way, don't know about other vendors, but on D-Link switches you can store either plaintext or encrypted passwords. config files will be like this:start implementing the hashed passwords as an option
create account admin admin
mymegapassword
mymegapassword
disable password encryption
create account admin admin
*@&5d86xdg6wvYoMp596eYmPiUkVXcQoIND
*@&5d86xdg6wvYoMp596eYmPiUkVXcQoIND
enable password encryption
because it's not important =) you should just lock your router in the steel safe - and all those problems are gone awayCan someone at mikrotik please look into this and give a proper explanation as to why this cannot be done?
LOL, sure if it was 1 rb... but on 600 nodes?!because it's not important =) you should just lock your router in the steel safe - and all those problems are gone away
perhaps ill just have to write my own winbox... download all the dll's off the rb's try & load them and see how it goes... If i have my own winbox password management system with filters & everything so I can display certain groups of nodes, I dont have a problem with 600 entries in my winbox db Right now, anyone can open up your winbox config file and see yet again your plain text passwords...use unique password for each RB, as it was said =)