I manage my accounts for websites with KeePass. This tool generates highly complex passwords, such as d,ªL¹(ç,z/¬gSÑ~}ÄwÚÆ¡íµ¯ó]ó6õ?Ô£fß,.
Such a complex password I use for example for Red Hat’s OpenShift website.
OpenShift servers/applications can be managed best by using their rhc command line tool.
Now, while running rhc setup I have to enter my password. So I copy it into the clipboard and paste it into the shell, where rhc sits and waits for my PW. However, the password won’t get accepted.
The process of pasting probably causes some changes. I already tried doing chcp 1252 and chcp 65001 before running rhc setup. Unfortunately this also didn’t help. The only way to get it running was changing my password to a trivial one on the OpenShift website, then doing the setup, and then changing the password back to a complex one.
Anyways, now I want to log in to my applications via rhc ssh, which is asking for the password of my ssh keys. And as everyone can guess, my ssh key is protected by a password in the style above. This is no problem because pasting such passwords into Putty or other GUI applications works great.
So I wonder: is there a way how I can do safe pasting into windows shells?
I commend you on your passwords!
There's two major possibilities:
Some characters need to be escaped
Shift to a longer password without the escape-requiring characters
Escape the characters!
Code page fun, i.e. some characters are being transformed
Figure out the mapping and duplicate your KeePass entry with one that will map to the correct values for that login type
Shift to a longer password without the escape-requiring characters
Assuming your password (unlikely) is a 35 character password using all 256 possible 8 bit values, that's a maximum exhaustive keyspace of 256^35, roughly 2E84 or 2^280. You can achieve a slightly higher maximum exhaustive keyspace with a password of 43 charactres containing Upper, Lower, Number, and normal US keyboard symbols (94^43), or 48 characters containing Upper, Lower, and Number (62^48).
The Upper, Lower, Number password of length 48 shouldn't cause any problems with escaped characters, and is far less likely to cause problems with code page transforms.
Note that both of those are likely to be superior against the edge case of an attacker who knows which characters were actually used :).
Note also that even a 35 character password containing only Upper, Lower, and Number has a maximum exhaustive keyspace of 62^35, or 5.4E62, or 2^208; 208 bits is likely to substantially exceed the amount of security provided by your transport layer and/or their storage mechanism.
*All passwords in this math are assumed to be 100% cryptographically random!
Related
I am trying to allow others to use my programs, but I don't want those users to be sharing the programs without my permission, so my goal is to prevent the users from doing this on the TI-84 calculator, but I have had no apparent luck.
For the TI-84 calculator, I have tried the getkey command and the stop. I have tried conditional statements with for and while loops, but I can't seem to prevent the user from sharing the code.
Prompt V
V+2 -> C
Disp C
The code works like it is intended but I can't prevent people from transferring this code to other calculators.
There is no way to prevent people from transferring programs over the calculator. What you could try to do is make it so that after you transfer the program yourself you store a password into a variable that they are unlikely to use (done manually, make sure to clear afterwards). When the program runs it checks if the variable stores the correct value. If someone else transfers the program and doesn't load the password into the correct variable, then the program won't work. However, they can figure this out by simply reading the code. If you want to be extra tricky, you can create a simple hashing algorithm and read from multiple variables. For instance, storing 123 in Z could be hashed by *28 + 54 mod 71 to get to 19. Apply those math functions to the chosen variables and then compare to their hashed value. This protects people from figuring out the password by checking the program (since 19 cannot be reversed to 123). Of course, they can just delete the check, so try to hide it somewhere among junk code. Now, they might overwrite those variables where your password is stored (often by running other programs that use those variables). Simply tell them that they have to come back to you so you can "fix" their program. Hope this helps.
Is it possible to automatically detect the escape sequence for a key combination?
, i.e., instead of running cat followed by pressing ctrl+right or ctrl+left manually to detect the escape sequence as ^[[5C or ^[[5D respectively, can it be automated? In that case, we may be able to send fn(ctrl+left) or fn(ctrl+right) as input to cat via pipe and get the output(for the first time, when ^[[5C or ^[[5D are unknown) directly.
fn(char a[]='ctrl+right') {..outputs the actual keypress signal for the input string a.. ;} | cat; fn=?
This question is the exact reverse of my other question https://stackoverflow.com/questions/34547008/reverse-map-the-keys-binding-value-to-the-key-combination.
I am asking this to automate the process of setting up key-bindings in the terminals, for devs, so that they need not run manually for all possible combinations, as we had to do now (as seen here)
Is it possible to automatically detect the escape sequence for a key
combination?
Since the shell (as any user program) has no insight into the terminal driver, it cannot predict what the driver will do with a key combination. Consider also that with certain terminals we can change the keyboard's behavior (e. g. cf. xmodmap). Automatic detection is not universally possible.
I have a command that essentially functions like clearing the memory, but doesn't wipe programs and sets the settings I like. I found out that while it does its job well, it doesn't seem to clear the equations in the Y= menu. Is there a command or another way to achieve this?
PROGRAM:CLEAR
:MATHPRINT
:Normal
...
:DiagnosticOn
:ClrDraw
:Clear Entries
:ClrAllLists
:SetUpEditor
:ClrHome
:"
On a similar note to TimTech, Delvar can be used to reset the value of a variable.
DelVar Y1
The benefit of this is that multiple DelVar calls can be chained without a line break.
DelVar Y1DelVar Y2Disp "Done
A non-programmatic way of clearing a calculator is to use the key sequence 2nd + 7 1 2. Unfortunately, this also clears programs.
This method will clear all RAM on the calculator, so use it with caution.
I found a better programmatic way of clearing the Y-VARS. This method also resets all other graph settings to their default value. In your case, this seems to be a desirable side-effect. Unfortunately, it requires a little bit of set up and occupies one of the Graph Database variables (119 Bytes). Because this variable can be kept archived, this does not consume any RAM.
Setup
Manually clear All Y-VARS, including parametric, polar and sequence variables.
Manually Reset All graph window settings to their default
ZStandard
RectGC
CoordOn
GridOff
AxesOn
LabelOff
ExprOn
Store current setting in a Graph Database variable
StoreGDB GDB1 entered with key strokes: 2ndPRGM◄5VARS3ENTERENTER
Archive GDB1
Archive GDB1 entered with keystrokes: 2nd+5VARS3ENTERENTER
Use in Program
To use this archived variable in a program, you must unarchive it, recall its contents, and finally archive the variable again. This is accomplished by the following code block.
UnArchive GDB1
RecallGDB GDB1
Archive GDB1
If you're using a TI-83 calculator, you need to skip the steps involving archiving because the TI-83 does not support flash memory. The TI-83 Plus and above work fine, however.
No command, but you can do "->Y1 or DelVar Y1 to clear Y1, and similarly for the others.
I understand the difference between ASCII mode vs binary when it comes to FTP, but what I don't understand is why there is even a need for ASCII mode at all? Is this just a legacy thing that used to save time by eliminating the most significant bit, therefore causing the overall speed of the transfer to increase by 1/8th? Or is there some hidden use for it that I don't know about?
I've encountered many problems because I would forget to switch the mode to bin when transferring text between different OS's. I don't understand why "bin" isn't just the default for everything, especially with today's much faster internet speeds.
Knowwutimean, Vern?
ASCII mode exists so you can get the right answer when you upload a text file to a remote system without having to know what the line termination or character set conventions are for that system. It was more important when transferring text files was more often done via FTP than, say, email.
To address your practical problem: check the documentation for both your FTP client and server(s) to see if there's a way to set ASCII mode by default. Often this is as simple as some kind of "profile" that sends some FTP commands every time you connect.
To address your philosophical problem: FTP is a 40 year old protocol that has its fair share of historical baggage. One day you'll be very glad that some protocol you depend on was standardized long ago and you can still access some old data.
I, for one, vote to eliminate ascii mode from ftp servers. Any EOL translation can be done by applications consuming the files, and many apps today understand both EOL types anyway. At a minimum, I'd like to see servers switch to using binary by default, and only use ascii if requested.
One scenario of practical use of ASCII mode is to upload PHP or Perl or similar scripts from Windows development machine to Unix server. Use of Binary mode would require separate conversion of line ending sequences, while with ASCII mode conversion is performed "automatically".
Update: there's one more scenario that we have come across - when transferring data to/from mainframes that use EBCDIC encoding, ASCII mode tells the server to perform conversion between encodings.
Here's a practical example of a problem that comes from using a binary FTP connection. In php there are two types of comments:
// a single line comment like this
/* a block comment like this */
The block comment has a start and an end. But the single line comment just ends at the end of the line.
If you upload a php file with single line comments using a binary connection, the php will stop running as soon as it hits the single line comment. It doesn't recognise the end of the line as the end of the comment, so it effectively comments out the rest of your php script.
If however you use FTP in ASCII mode, it will correctly read the end of the line and will run your php code as expected.
I am using a FTPS connection to send a text file
[this file will contain EDI(Electronic Data Interchange) information]to a mailbox INOVIS.I have configured the system to open a FTPS connection and using the PUT command I write the file to a folder on the FTP server.
The problem is: what mode of file transfer should I use? How do I switch between modes?
Moreover which mode is the 'best-practice' to use when transferring file over FTPS connection.
If some one can provide me a small ftp script it would be helpful.
Many of the other answers to this question are a collection of nearly correct to outright wrong information.
ASCII mode means that the file should be converted to canonical text form on the wire. Among other things this means:
NVT-ASCII character set. Even if the original file is in some other character set, such as ASCII, EBCDIC or UTF-8. Technically this disallows characters with the 8th bit set, but most implementations won't enforce this.
CRLF line endings.
EBCDIC mode means a similar set of rules, except that the data on the wire should be in EBCDIC.
LOCAL mode allows sending data with a size other than 8 bits per byte.
IMAGE (or BINARY) mode means that the data should be send without any changes. It is up to the user to ensure that the target system can understand the data once it arrives.
Among other things, this means that the recommendation to use BINARY mode to send text data will fail if one of the systems involved doesn't use a ASCII based character set.
ASCII mode changes new line characters between unix and DOS formats. \n to \r\n and viceversa.
Actually, ASCII/BINARY has nothing to do with the 8th bit. It's a convention for translating line endings.
When you are on a windows machine talking to a Unix FTP server (FTPS or FTP - doesn't matter - the protocol is the same), the server will replace any <CR><LF>-Combination with <LF> before storing the file and consequently do the translation in reverse in case you get the file from the unix server.
The idea behind ASCII mode is to convert the line endings to the respective endings of the target platform.
As todays world seems to be converging to the unix convention (<LF>) and as nearly all of todays editors (aside of notepad) can easily handle Unix-Line-Endings, the days of ASCII mode are, indeed, numbered and I would by all means recommend to always use BINARY transfer mode.
The prospect of having data altered in mid-transfer is somewhat frightening anyways.
ASCII mode also makes file sharing of text files across different platforms more straightforward for end users. They won't have to worry about the default line ending (cr/lf versus just lf for example) since the ASCII mode will do that translation for them on the fly.
For most file types you will ALWAYS want to use BINARY mode though.
ACSII mode converts text files between UNIX and Windows formats based on the server and client platform (CR/LF vs LF), Binary doesn't. Of course, if you transfer nearly anything in ASCII mode that isn't text, it will probably be corrupted for that reason.
If you want an exact copy the data use binary mode - using ascii mode will assume the data is 7bit text (chars 0-127) and truncate any data outside of this range. Dates back to arcane 7bit networking days where ascii mode could save you time.
In a globalized environment that we live in - such that it is quite common to find non-ascii characters e.g. foreign languages, currency symbols etc. - you should always use BINARY mode.
For the FTP protocol, the ASCII transfer mode will consider the 8th bit of each of your character as insignificant and will use it for error checking. As for binary transfer mode, your data will be sent as is. Note that sending binary data in ASCII mode will (almost) always end up in data corruption. However, transferring ASCII data in binary mode will work as long as the sending and receiving systems use the 8th bit in the same way (in modern system the 8th bit should stay at 0 to prevent collision with extended ASCII charsets).