5

I've been searching for a getpass() alternative and it's in fact the simplest way to hide a password input I've founded. It's kind of a loss for C++ here, being such easy function with a lot of use.

What i would like to know is why is it considered obsolete, does it have any security issues ?

And can/should i still use it professionally, disregarding the warnings and taking them as "exaggerated" ?

Klitos Kyriacou
  • 10,634
  • 2
  • 38
  • 70
Frederico Martins
  • 1,081
  • 1
  • 12
  • 25
  • alternative: http://stackoverflow.com/a/1196696/2805305 – bolov Jan 22 '16 at 11:57
  • @bolov, thanks i'm aware of the alternative, what i would like to know is why is it obsolete. – Frederico Martins Jan 22 '16 at 12:06
  • Possible duplicate of [Getting a password in C without using getpass (3)?](http://stackoverflow.com/questions/1196418/getting-a-password-in-c-without-using-getpass-3) – Thomas Dickey Jan 22 '16 at 12:26
  • @ThomasDickey, the question is nothing like the one being asked in [there](http://stackoverflow.com/questions/1196418/getting-a-password-in-c-without-using-getpass-3) – Frederico Martins Jan 22 '16 at 14:06

2 Answers2

5

Why is getpass() considered an obsolete function?

According to this man page

The getpass() function is not threadsafe because it manipulates global signal state.

The getpass() function is scheduled to be withdrawn from a future version of the X/Open CAE Specification.


can/should i still use it professionally

If your C library has the function, then you can use it.

If you consider any of: the lack of thread safety, or the manipulation of global signal state in general, or the fact that as an obsolete function it may be removed in a future version of the C library that conforms to a future POSIX version, a problem, then you should not use it.


The recommended alternative is to write your own function, using termios and disable the ECHO flag. Complete minimal substitute in glibc manual.

rlee827
  • 1,853
  • 2
  • 13
  • 32
eerorika
  • 232,697
  • 12
  • 197
  • 326
  • Great answer, thanks, i think i will have to find another way then. Why isn't it modified to be more friendly and instead gets obsolete ? – Frederico Martins Jan 22 '16 at 12:19
  • 1
    @Flippy Wild guess: maybe because modifying it to remove the problems would require changing its signature. – Angew is no longer proud of SO Jan 22 '16 at 12:20
  • @Angew, pardon my bliss, but what is the problem behind changing the signature ? – Frederico Martins Jan 22 '16 at 12:25
  • 1
    @Flippy code working with current function will stop working. Think about it as removing function and adding new one which happens to have same name. So far first part was considered. Maybe second one will be done too sometime. – Revolver_Ocelot Jan 22 '16 at 12:28
  • 1
    @Flippy Backwards compatibility. I would guess that a safer replacement is already available (probably introduced at the same time `getpass` was deprecated), but `getpass` itself must keep its signature not to break existing programs. – Angew is no longer proud of SO Jan 22 '16 at 12:28
  • 2
    @Flippy I'm also just speculating, but `getpass` appears to be a convenience function and therefore not essential. Perhaps there isn't one single way to implement it that it will work for everyone. Maybe an alternative convenience function will be proposed - I don't know how much POSIX evolves these days. – eerorika Jan 22 '16 at 12:29
  • Hum, I figured that much. Well, I'm all answered and i will look into the `termios` solution, thanks y'all ! – Frederico Martins Jan 22 '16 at 12:32
2

The term "obsolete" appears to be an add-on from implementers; the actual SUSv2 was less direct:

The return value points to static data whose content may be overwritten by each call.

This function was marked LEGACY since it provides no functionality which a user could not easily implement, and its name is misleading.

The "obsolete" is mentioned in mailing list in 2003 Re: getpass obsolete?, which pointed to an OSF1/Tru63 manual page citing the lack of thread-safe capability, but in regard to the standard at that point in time was only supported by the comments in SUSv2.

Community
  • 1
  • 1
Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105