I'm finding it hard to see how it would be more secure. If I understand what the other comment meant, they would have something like:

password123 = ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f

We'll assume they pick 4 random pairs

3rd + 5th (sw) = 7865b7e6b9d241d744d330eec3b3a0fe4f9d36af75d96291638504680f805bfd
9th + 11th (13) = 3fdba35f04dc8c462986c992bcf875546257113072a909c162f7e470e581e278
2nd + 5th (aw) = f5fe88ee08735ae259265495a93c8de2b0eacfecf0cd90b5821479be3199fa8c
6th + 8th (od) = 32f30ea0e83c41a331c4330213005568675f7542c25f354ebb634db78cc30d12

Assuming all 128 7bit character options are used and ignoring dictionary or optimized attacks the complexity of the full password is 7x11 or 77 bits (or 151,115,727,451,828,646,838,272 combinations). So with just the password hash that's how many tries you need to exhaust every possible option, again without optimizing the process.

But for each of the pairs the complexity is 14 bits or 16,384 combinations. So it would take microseconds to crack all 4 of the pairs. With that information you'd get a password of ?as?wo?d1?3?????? (because we don't know the length) and if they have used a common word or series of words you might have enough information to guess the rest, but even when brute forcing you've removed a decent amount of complexity.

Note: This is SHA256. We're going to ignore salt for this. Salt only increases complexity because you need to crack each user's password and not able to really use rainbow tables etc.

Unless I misunderstood the idea. In which case, sorry about that.

In all likelihood it is encrypted in a database and the interface to the phone operator only allows them to enter what is said and confirm (although I wouldn't be surprised of some showing the whole password).