Joined: Sat Apr 04, 2009 10:57 am Posts: 68
Karma: 0
I am stuck with a very silly mistake. I had a problem with my Mikrotik router OS, I simply did a restore for a backup I had done two months ago. Now I am stuck as my password has also been restored and I cannot remember what my password was at that time. Any help apart from re-installing the RouterOS again
Joined: Sat Apr 04, 2009 10:57 am Posts: 68
Karma: 0
Onother silly one, The backup is still on the router PC, how can I get it out of there. Can I remove the harddisk and connect it externally to my laptop and be able to get it on a Windows machine?
How so? I'm pretty confident you'll not break the current AES encryption any time soon. Current Linux password storing methods are considered quite safe. So I'm a bit surprised about your comment (and that any kind of encryption can be broken easily is just plain untrue, so you must mean something else I'm missing).
Joined: Sat Apr 04, 2009 10:57 am Posts: 68
Karma: 0
Ok, what I mean is that the backup I need to put in the link provided. But the problem is that the backup is in the router OS and not in my computer. So is there a way I can get the backup from the router OS then copy it into my laptop and extract the password. The router PC is here with me and is working properly after the restore but I cannot log into winbox becoz of password change.
Joined: Fri May 28, 2004 10:04 am Posts: 16951 Location: Riga, Latvia
so? this doesn't help, either the backup file wouldn't be transferible to other PC, or the potential cracker would just have to find where the key was taken from.
Normis, don't feign foolishness. if you save only (machine-independent) hash for password - then you cannot just enter it into 'password' box (even if you got an access to the router files and read the hash value), you need initial non-hashed password to pass authentication. and if your password is not short - then you need bruteforce attack to restore password from hash. that's it, hash function is one-way
I'd like the cracker to restore my passwords in weeks, not in seconds
_________________ For every complex problem, there is a solution that is simple, neat, and wrong.
Joined: Fri May 28, 2004 10:04 am Posts: 16951 Location: Riga, Latvia
about backup file:
The only thing that you can use for your hash generation is software-id. Everything else can change. If we silently encrypt it with software-id, you won't be able to recover from backup on another router.
If you have to remember some password it's probably better if it is meaningful to you and not some random digit sequence.
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.
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.
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
p.s. my 6000th post
_________________ For every complex problem, there is a solution that is simple, neat, and wrong.
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
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.
Chupaka wrote:
p.s. my 6000th post
Now you can move from quantity to quality (joke)!
_________________ I know what i don't know, do you?
_________________ انا انزلنا التوراه فيها هدى ونور يحكم بها النبيون الذين اسلموا للذين هادوا والربانيون والاحبار بما استحفظوا من كتاب الله وكانوا عليه شهداء فلا تخشوا الناس واخشون ولا تشتروا باياتي ثمنا قليلا ومن لم يحكم بما انزل الله فاولئك هم الكافرون
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).
Last edited by Jeroen1000 on Tue May 31, 2011 1:06 pm, edited 1 time in total.
Joined: Fri May 28, 2004 10:04 am Posts: 16951 Location: Riga, Latvia
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).
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.
if you have some idea how to overcome this limitation, we will be happy to make it.
Chupaka can explain better I think. You can't log in with the hash. It is used for a different purpose.
Basically, say my password is 1234 and the hash is 0FBECDE5. You store the hash.
Next time someone inputs, lets say 4567. If you hash 4567 you will never ever ever get 0FBECDE5 but for instance 0FABACDE. So, in order to grant access you compare 0FBECDE5 with the HASHED version of 4567. They will not match.
I.E. 0FBECDE5 does not match 0FABACDE
The only way you will ever get 0FBECDE5 as a hash again, is when you input 1234 as a password. Ofcourse there is no way of converting 0FBECDE5 to 1234. It is only possible to create 0FBECDE5 by hashing 1234: you can not find out what the password is by looking at the hash. I'm not expert either, just to make clear:). But a security enigeer should have little trouble cooking something like this up. It's very widely used.
I'm just very in favour of strong security and privacy minded. You definetely require someone with more knowledge than myself to implement this securely but should not be very hard to so so.
Joined: Fri May 28, 2004 10:04 am Posts: 16951 Location: Riga, Latvia
you still can retrieve 0FBECDE5 from the router just like the second post of this page describes, and log in by using 0FBECDE5 directly. you don't need to know what password made this hash
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.
agree, I need a coffee... =)
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.
yes, in case of network login. but it's completely impossible when using local login when somone is knocking to you via network - firewall is on stage; but you cannot know who's on COM port. so, protect your management IP network and don't give them possibility to get to know your plaintext password
_________________ For every complex problem, there is a solution that is simple, neat, and wrong.
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.
Joined: Fri May 28, 2004 10:04 am Posts: 16951 Location: Riga, Latvia
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.
Could you just please check with your engineers. This kind of protection is as common as HTTPS websites. I can give you my Trurecrypt encrypted hard drive and you"ll never get access to my data when the drive is at rest (powered off). It also uses local login.
Chupaka is not saying at all this is not possible (but only he can set the misinterpretation straight). I think the best course of action is to just ask the engineers what they can implement. Or you could check out a how it is done on any Linux distro?
We all know that it is completely unacceptable to send password over network in plain text, so we want to send some kind of hash. But to verify that hash we need plain text password on the router. It is possible to store password as hash and send over network hash of that hash. But in this case your hash of the password becomes real password. Of course, you would have to crack winbox to feed in this hash instead of plain text password, but in case of API only hash would be sent, so it would be trivial to write simple script that knows only your hash from backup and connects to your router via API and changes password.
Windows stored passwords has MD4 hashes. Because of that MS could not support CHAP authentication. They invented MS-CHAP, that was using this hash as a real password. MS even extended PPP protocol so you can change password remotely. The end result? Lookup in the internet... It was enough to know this MD4 hash to dial-in into windows computer and change it's password.
Bottom line is - from security point of view gain of this feature request is close to none, as we all know that using same username/password on all the routers is plain stupid anyway.
_________________ I know what i don't know, do you?
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
_________________ For every complex problem, there is a solution that is simple, neat, and wrong.
Joined: Thu Mar 19, 2009 10:58 am Posts: 34
Karma: 1
I have been directed to this thread when I raised the issue of insecure passwords to support.
Here is my view: You cannot use "keep your backup file safe" as an excuse to a very poor security design. And using 400 different passwords is also not an option (we manage 400 nodes). We have users that manage their own nodes, so they have an admin user on their node, while we also have an admin user on their node.
The solution is quite simple: Firstly, winbox should connect to the router via SSL, not via an unsecure link. Then sending plain text passwords is not a problem.
Secondly, the router has absolutely no business storing a local copy of the password. It should only ever store a hash. Yes, there are debates on how secure a hash really is, if I use the password "123" and it is hashed using md5 then sure, it is useless. But if I use "myUberseCretp@ssword!@##$%#$%^#$%^@#$^WHATEVA" and it uses SHA384 to hash, I am sure that it will be safe for a while.
So, Mikrotik, apart from not wanting to change things, why don't you implement this?
I would be happy if you started adding it to Ros 5.5 as an optional feature, and guess what? If I decide to rather hash my passwords then I cannot use The Dude, or Bandwidth test, or some such. Fine by me.
If you can make it a per user option it would be even better, as then I can create a readonly user for bw tests, dude etc, and keep my management user password safe.
Joined: Thu Mar 19, 2009 10:58 am Posts: 34
Karma: 1
I did read.
macgaiver wrote:
But to verify that hash we need plain text password on the router.
Bullshit.
You do not need to have the plaintext password so that you can hash it and compare the hash. What the hell?
Procedure: I type password "secret" into winbox and click login. winbox creates a secure connection to my rb. rb receives password "secret". rb hashes the password using whatever cool function you guys decided to use, and the result is "alskdfjlkasdjflkjfjwelksadjfklavnqewruoihtjnbpagdfhajoksehfaoierufhhasjdfnanseruthsdgufhnsadfgu" rb loads the local copy of the password hash (also "alskdfjlkasdjflkjfjwelksadjfklavnqewruoihtjnbpagdfhajoksehfaoierufhhasjdfnanseruthsdgufhnsadfgu") they match, user can continue.
Another user types "blabla" into their winbox. winbox creates a secure connection to my rb. rb receives password "blabla". rb hashes the password using whatever cool function you guys decided to use, and the result is "pwermasdofqwoiefjvnmanwerpoitjokiamscvknawoeirjoiwefaklosnfoaiwefjasoifj" rb loads the local copy of the password hash: "alskdfjlkasdjflkjfjwelksadjfklavnqewruoihtjnbpagdfhajoksehfaoierufhhasjdfnanseruthsdgufhnsadfgu" hey, what do you know, they don't match! user may NOT continue.
Tell me again why the rb needs to store the plain text password?
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
btw, if we elaborate that thought, everybody should use other vendors' equipment, not to bother MikroTik =)
_________________ For every complex problem, there is a solution that is simple, neat, and wrong.
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
_________________ For every complex problem, there is a solution that is simple, neat, and wrong.
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
Joined: Thu Mar 19, 2009 10:58 am Posts: 34
Karma: 1
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
So should the API not be update to take the text given, hash it, then compare that with what is stored on file?
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
_________________ For every complex problem, there is a solution that is simple, neat, and wrong.
Joined: Thu Mar 19, 2009 10:58 am Posts: 34
Karma: 1
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
They could send MD5("\x00" + saved_hash + challenge), the client can hash the password and compare. The router still does not need to store the original password.
And if you use a very good hash algorithm (not MD5) and your user uses a proper password, then it will be secure.
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 router
_________________ For every complex problem, there is a solution that is simple, neat, and wrong.
Joined: Thu Mar 19, 2009 10:58 am Posts: 34
Karma: 1
TFyre wrote:
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
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.
The sad thing is that this completely breaks our admin model on our network. We cannot prevent nodes from creating backups that contain the core admin team password, nor can we run with 400+ different password.
Mikrotik, any chance that you can start implementing the hashed passwords as an option on each username. That way we can secure the users that we want to secure, and if it means that user cannot be used by the API or by The Dude, then so be it. That would give you a great way to start moving over to the hashed auth model over the next few releases until it is fully supported.
start implementing the hashed passwords as an option
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:
Users browsing this forum: Google [Bot] and 16 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
Login |
HOME
?
