If the computer is an AI (that is, analogous to an NPC), I might try TELL COMPUTER THE PASSWORD IS [password] or just TELL COMPUTER [password] if it has just asked for it.
That said, as an author, I would change the prompt to say I want the password, and hope the player realises that it is only the password to be typed!
I think this is probably ideal from a usability standpoint, and if you’re really worried about the fraction of players who will kvetch about immersion you could always make the bracketed tooltips an option you can disable.
I think from a general gamedev standpoint what you want to do is draw a circle around all the gameplay elements that are so common that anyone familiar with the gamplay genre will know them without having to have them explained. The instructions for using those go in the documentation (if you’re enough of a traditionalist to do documentation) or in an optional tutorial.
Then you identify the bits that aren’t part of the “default” gameplay mechanics. Some of those are going to be puzzles or something else the player is supposed to have to work out for themselves. Those get cued/hinted in the gameplay. The remaining bits…the things that aren’t part of the standard mechanics of the genre and aren’t intended to be puzzles…should probably get hinted/cued proximate to their first use. Depending on how confusing you expect the mechanic to be you can either cue once (display the suggested usage the first time the laptop is examined) or every time.
For the game I’m working on, which (intentionally) has a number of idiosyncratic gameplay conventions, I’m thowing a couple of general techniques at this sort of problem:
>TOOLTIP verb that gives usage information (as opposed to hints) about the specified object/topic…so for example >TOOLTIP LAPTOP would display your bracketed usage message.Basically the “gimmick” is that when the player encounters a new widget they’re either going to already know how to interact with the widget or they’re going to have to learn a new gameplay rule about interacting with the widget…and (unless figuring out how to interact with the widget is a puzzle) you want to provide the player with a general scheme for figuring out how to interact with things. That is, you want to give then a rule for how to handle rule acquisition, rather than look at it as an isolated one-off about how to cue an individual puzzle.
I would dislike anything that made it effort to enter individual letters.
I think you should use the setup to enhance your story. Is the player hacking into an evil corporation? Have the prompt for password be impersonal and cold. Are they infiltrating a government agency? Have it be convoluted, outdated and buggy.
I would look at modern web design standards for password entry fields and then skew those concepts to reflect the narrative you want to convey.
My two cents:
I would expect this to work - or at least provide a helpful error message - and start looking for hints if it didn’t.
Ideally, this should also work unless it is important that there are several computers/keypads/whatever in the same room.
In a perfect world, this should also work.
This is totally fine with me since, as you say, there’s no real standard for entering passwords.
TYPE PASSWORD [ON COMPUTER] is the first thing I’d try. I would never come up with the phrase ATTEMPT PASSWORD. Whether to make the parser prompt become the computer’s prompt, that depends on what further interaction there might be.
If there’s a realistic command line (like Dunnet), maybe prefixing every command with TYPE is not great. But if the player will also CLICK OK or something like that, it’s more consistent not to take over the prompt. I like the idea of accepting just the password as a command, without the word TYPE, but more as an easter egg for adventurers. It’s not really intuitive.
If there’s no further interaction it matters less, but I’d think that taking over the prompt makes the computer system more real, but TYPE makes it more real as an object.
/old curmudgeon mode ON
I suspect that you’re young…
I don’t want to bash(1) you 
but computers and OS always have a thing called “command line interface/shell”, e.g. here:
in particular, this passage ought to be read by everyone implementing computers in an parser IF:
The commands given to a CLI shell are often in one of the following forms:
where doSomething is, in effect, a verb, how an adverb (for example, should the command be executed “verbosely” or “quietly”) and toFiles an object or objects (typically one or more files) on which the command should act.
Best regards from Italy,
dott. Piergiorgio.
What I mean is that if the prompt becomes the computer’s prompt, the player character and their environment temporarily vanish, and it becomes just the player at a realistic terminal.
If computer operations are accomplished through commands to the player character, they remain more present, as well as the rest of the room and the computer as a physical object.
partly concur with paul above:
SIP HACK FLUID
You take a good gulp of your favorite coffeine-based drink.
PROGRAM COMPUTER
With your brain’s gears well lubricated from coffeine, you manage to implement 27 rooms, 19 objects and 8 puzzles into a working testing IF.
X IF
More a testing & messing arena than a release-grade IF; one object you have still unimplement is a computer.
X COMPUTER OBJECT
It’s still incomplete; you haven’t figured the best implementation for the concluision of your epic password-gathering puzzle. But the disambiguation between the computers was a major challenge… perhaps browsing the intfiction community can help ?
BROWSE INTFICTION FORUM
In the forum you found what you really needed ! actually more than you really needed: in a long 28-posts forum you get at least three different ways to implement a password-entering mechanism !
[your score goes up 25 points !]
(I 'fess up: I actually drinked hack fluid prior of replying, generating the rather elaborate example script above…)
Best regards from Italy,
dott. Piergiorgio
Infocom’s game, The Lurking Horror, managed this by implementing two special commands, “LOGIN” and “PASSWORD.”
Thus,
Login 872325412
Password UHLERSOTH
…gets you into the terminal at the start of the game.
(Post Scriptum: It says something about me, that I entered both the login number and the passwoed itself, from memory.)
(Post Post Scriptum: This implementation always irked – and still irks – me, because the game has already prompted, “Login Please:” and “Password:”. What is the point, when the computer has already explicitly asked for a password, of forcing the player to preface his entry with “Password”? When the computer prompts “Login:” or “Password:”, that should be precisely all that the player should need to enter! And that would be my advice to YOU, too.)
Hahahahaha 
Agreed. This is why in a puzzle I’m working on (which uses interactive computers), all computer commands are prefaced with TYPE as in >TYPE CD ~/DESKTOP and >TYPE LS.
It was more important to me to have the player participating in the room, and be able to smoothly access inventory and examine stuff, as opposed to needing to start and stop a computer session, so that the input prompt is piped correctly. I suppose a workaround for this is to treat computer contents as true world objects, but you would need to figure out how to safely handle commands specifically for these. You wouldn’t want a weird response for >EAT TEXT FILE, for example.
But again, that’s why I made my own parser for handling computer commands, and simulated files and folders as actual data, instead of world objects in the room.
Okay… And how do we handle a Windows PC or Mac? Should I look to implement:
> DOUBLE CLICK GOOGLE ICON
> RIGHT CLICK START BUTTON
I’m leaning towards no maybe, just because a parser is already similar to command line. For what it’s worth, I usually try to implement both basic Unix and Windows command-line commands, because people who already know how either works can just use it, and anyone new to it only need to learn maybe 4 basic commands from >TYPE HELP.
This also technically mimics Windows, Mac, and Linux.
Or, you can also just make up a totally fictional OS and make up all the commands that you can type in, and not base it on anything real. That’s a completely valid option, which could be a lot of fun!
Again, I just add basic Unix and Windows commands because I’m not adding any advanced stuff (like pipes, etc), and I have a suspicion that there would be requests from Command Prompt and Unix Terminal users to add synonyms/alternatives to support their existing command-line habits.
Also…
…having more actions than just TYPE might require you to implement actual world objects in the room, which can get complicated and bug-prone quite fast, especially when you have to do really tricky stuff with the world model.
However, if you can get it to work without any exploitable bugs, then that could be really excellent.
>X SCREEN
You see an Internet icon and the user folder.
>CLICK ON USER FOLDER
The screen shows the contents of the user folder, which include a text file named "README".
>CLICK ON README
The contents are as follows:
"Congratulations, you've read me!"
>TAKE README
That seems to remain in the computer.
You can use these or just TYPE.
Heh, same here. I memorized those back in the 80’s and they never faded.
Sometimes I think it is weird that I can remember how to navigate worlds and mazes in the huge number of games I played decades ago.