normis wrote:any kind of encryption can be broken quite easily
singh wrote:is there a way I can get the backup from the router OS then copy it into my laptop and extract the password.
normis wrote:to encrypt something, we need a key. you would have to provide a password that you would have to remember.
normis wrote:but 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.
Chupaka wrote: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
Chupaka wrote:p.s. my 6000th post
Jeroen1000 wrote: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).
macgaiver wrote: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.
normis wrote: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.
Jeroen1000 wrote:No, 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.
macgaiver wrote:as we all know that using same username/password on all the routers is plain stupid anyway.
macgaiver wrote:But to verify that hash we need plain text password on the router.
Chupaka wrote:macgaiver wrote:as we all know that using same username/password on all the routers is plain stupid anyway.
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 comprimise
PietRetief wrote:Tell me again why the rb needs to store the plain text password?
Chupaka wrote:PietRetief wrote:Tell me again why the rb needs to store the plain text password?
because API protocol does not support encryption %(
p.s. that's not true, they can store pre-calculated not finished MD5("\x00" + PWD) value for API logins
Chupaka wrote: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
PietRetief wrote:They could send
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
PietRetief wrote:start implementing the hashed passwords as an option
create account admin admin
disable password encryption
create account admin admin
enable password encryption