The typical lack of access to the password hash in the shadow file may make this request problematic for a random userland program to use the system password database, as sudo and chsh and such tend to have the setuid bit set on them so that they run as root and can access the shadow file.
[jdoe@centos ~]$ id -u
1001
[jdoe@centos ~]$ perl -E 'say for getpwuid(1001)'
jdoe
x
1001
1001
/home/jdoe
/bin/bash
[jdoe@centos ~]$ sudo perl -E 'say for getpwuid(1001)'
jdoe
$6$P1jejm1i$bo02c/...
1001
1001
/home/jdoe
/bin/bash
[jdoe@centos ~]$
Once a program can obtain the password hash for a user (whether from the system database or some other source, it's the redacted $6$P1jejm1i$bo02c/... bit in the above output), a traditional crypt(3) call should suffice to verify the password.
A password prompting program might also want to prevent core dumps, lock itself into memory, scrub various bits of memory afterwards, and ignore various signals, among even more stringent checks if run setuid, in addition to not echoing the password. OpenBSD makes some of these steps easy via readpassphrase(3) though other OS not so much with getpass(3) being marked as LEGACY...