Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

A new concept for passwords

edited May 2014 in Code Sharing Posts: 1,976

Just a concept I've been working on...but I've been thinking about passwords, how hard they are to remember, and how time-consuming it can be to type in a long one.

So I got an idea, for a "passdrag." It's pretty simple, you just drag a dot around in a circle at different angles. Then that movement of dragging the dot, and all the angles it passed, is turned into a numerical code.

I'm not saying this would be pratical for more secure things, but for something like a 4-digit passcode, like on an iPad, it would take around the same time to enter it, and would be much more secure.

View via GitHub

View via Pastebin

View via Codea Community

Again, just a concept. Feedback or opinions are greatly appreciated!


  • dave1707dave1707 Mod
    Posts: 8,674

    @SkyTheCoder An easier concept that is being used is to show a picture and you touch different objects in the picture in a certain sequence for your password. I think that's easier than trying to drag a dot at different angles.

  • Posts: 1,976

    @dave1707 But that's no different than a PIN! Passdrags can have any length, and can be done in one swift movement.

    There's only 8 different angles, and it's pretty hard to mess up. The dot isn't that small, either.

  • dave1707dave1707 Mod
    Posts: 8,674

    @SkyTheCoder The number of pictures that can be touched can be any length also. Only the person who setup the original sequence knows how many pictures and in which sequence they need to be touched. I could probably touch pictures faster than I can drag a dot at certain angle. Also, if you have to drag a dot at different angles, then it's not one swift movement, but different movements at different angles. I think you're increasing the pin. If I have a pin that's 74258953, that's 8 digits to remember. If I have to remember 8 angles, that might be 45 90 180 0 135 90 270 180.

  • Posts: 2,043

    @SkyTheCoder, nice idea. I like it. @dave1707, I think it is pretty easy to remember which way to turn and where to stop / turn around. Plus, it can be as short (or as long) as you want.

  • edited May 2014 Posts: 1,976

    @Prynok suggested specific sounds being played when you hit a different angle, does anyone else want to try it?

    @dave1707 You don't have to remember the angles in degrees, think of it as 1-8, like the output is. 1 is top, 2 is top right, 3 is right, etc. It's also easier than an 8-digit PIN because the numbers are in order, it can only jump one at a time, i.e. 1-2-3 instead of 1-3. That makes it a bit easier to remember, and increases the length of the code without you have to remember the ones in between. You can just remember to drag from 1 to 3, and it adds the 2 in automatically. That also makes creating a program to figure out a drag harder, because most of the codes it generates would be impossible to drag, without having it filter out all the ones without numbers in order.

    @JakAttak Thanks!

  • dave1707dave1707 Mod
    Posts: 8,674

    @JakAttak @SkyTheCoder I guess I would have to see it in action to see how easy it would be to remember.

  • Posts: 1,976

    @dave1707 You mean you rejected my idea without even trying it...?

  • edited May 2014 Posts: 2,043

    @SkyTheCoder, @Prynok, I added functionality to play a specific sound at each mark, it just sounded annoying. I wouldn't add it, or at least put an option to turn it off.

    Also I tried it with a smaller size (100) and thought it still worked well.

  • Posts: 1,976

    @JakAttak I just remembered that I got the idea a few days ago but turned it down, and I also just remembered why. What if you were in a public place, someone heard the sounds played while you put in your passdrag, and they remembered what order? If they got ahold of it, they could theoretically drag out the code by recognizing the sounds again.

  • Posts: 2,043

    @SkyTheCoder, I made a few small changes to the code in main (and a few in Passdrag class just to change look a bit).

    I took out a lot of the stuff in the output window and moved it to the screen. I also removed showing the pass because someone could just look over and see it. And same reason for removing the saved pass (plus you can overwrite it easily)

    Here it is:

    --The MIT License (MIT) -- --Copyright (c) 2014 SkyTheCoder -- --Permission is hereby granted, free of charge, to any person obtaining a copy --of this software and associated documentation files (the "Software"), to deal --in the Software without restriction, including without limitation the rights --to use, copy, modify, merge, publish, distribute, sublicense, and/or sell --copies of the Software, and to permit persons to whom the Software is --furnished to do so, subject to the following conditions: -- --The above copyright notice and this permission notice shall be included in all --copies or substantial portions of the Software. -- --THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR --IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, --FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE --AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER --LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, --OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE --SOFTWARE. function setup() print() pd = Passdrag(WIDTH / 2, HEIGHT / 2, 175) styles = {"Nature", "Light", "Dark", "Retro", "Sky"} parameter.integer("Style", 1, #styles, 1) parameter.action("Save Passdrag", function() savePassdrag() output.clear() print() tween.delay(0.1, function() output.clear() print() print("Passdrag saved") end) end) end function draw() pd:setStyle(styles[Style]) background(pd.styles[].bg) pd:draw() font("HelveticaNeue-Light") fontSize(48) fill(pd.styles[].txt) text("Passdrag", WIDTH / 2, HEIGHT - HEIGHT / 16) fontSize(24) text("Theme: " .. styles[Style], WIDTH / 2, HEIGHT - HEIGHT / 8) text("Drag Length: " .. pd.sequence:len(), WIDTH / 2, HEIGHT - HEIGHT / 6) text("Matches Saved: " .. boolToStr(checkPassdrag()), WIDTH / 2, HEIGHT / 6) end function touched(touch) pd:touched(touch) end function savePassdrag() local fileName = "passdrag.txt" local file = os.getenv("HOME") .. "/Documents/" .. fileName local wFd =, "w") wFd:write(pd.sequence) wFd:close() end function readPassdrag() local fileName = "passdrag.txt" local file = os.getenv("HOME") .. "/Documents/" .. fileName local rFd =, "r") local v = "" if rFd ~= nil then for i in rFd:lines() do v = v .. i end end if rFd ~= nil then rFd:close() end return v end function checkPassdrag() return pd.sequence == readPassdrag() end function boolToStr(bool) local str = "false" if bool == true then str = "true" end return str end
  • Posts: 1,976

    @JakAttak Displaying the saved drag is just so you can see what it looks like. It's only in main, not part of the class. For real use, it wouldn't show the numbers.

    As for changing the styles, it's built in, you don't need to change the code. If you want to set, say, the fill color for the current style, you can say Passdrag.scFill = color(255). You can also use Passdrag.addStyle(x, y) to add a new style x with the presets y. The preset structure is:

        bg: color (suggested background color)
        txt: color (suggested text color)
        cFill: color (fill color)
        cStroke: color (stroke color)
        cDark: color (darkened color, as seen while the dot is pressed)
        pWidth: number (stroke width)
  • IgnatzIgnatz Mod
    Posts: 5,396

    @SkyTheCoder - ultimately, your passdrag ends up as a sequence of numbers that is used to unlock your program. So the steps are
    1. touch sequence
    2. convert to number sequence
    3. test against password list (perhaps in hash form)

    What is to stop me hacking your program to bypass step 1 and 2, and simply generate a series of number sequences that are fed directly into step 3 until one works?

    What is important then, is that the number of possible combinations is astronomically high - I'm not a cryptographic expert, but perhaps 2^128 - and also that there are not some finger patterns which are very common, making it easier for an attacker to try those first. That would require a great deal of user testing.

  • IgnatzIgnatz Mod
    Posts: 5,396

    @SkyTheCoder - addendum - I have played around quite a lot with encryption and scurity in the past, and it is extraordinarily difficult to get right. The experts will tell you that people are always coming up with bright ideas, but that they nearly always fall down somewhere.

    They also advise that before you think about creating a new crypto approach, you should try cracking some existing systems first, to get an idea of the vulnerabilities you need to avoid.

    And your idea is nice, but (with no disrespect) it is fairly obvious, and I'm sure you can imagine that many smart people have thought of it before now - especially Apple! If it was easy to do, it would be in use already.

    Don't let me put you off playing with this stuff, all I'm saying is that if you want it to be taken seriously, there is a horrendously huge amount of highly skilled work to be done before anyone would even look at it.

  • edited May 2014 Posts: 1,976

    @Ignatz First off, it's not my program that does any passcode checking. It only supplies the GUI and the output from it, you have to program the actual authentication.

    Your steps 1 and 2 are actually only one step, because as you drag your finger around it adds the numbers. You could move the dot to write your drag in any number of touches.

    It's more secure than a PIN because you write over 20 characters in less than ten seconds. Any password could be cracked using a simple algorithm that loops through all the possibilities, so why is mine any more vulnerable? It's actually a bit less vulnerable to that, because since the numbers can only be in order (1357 is not possible, it would HAVE to be 1234567) most of the codes it generated would be unusable. But again, since my program doesn't supply any authentication, you have to make it yourself, and I have no control over it.

    Edit: I also don't do any encrypting. This entire concept is purely a GUI that outputs a string of numbers. I don't do any validation, authentication, encryption, etc. That is all done by you. If you're going to judge my app, base it on the GUI, how it looks, how easy it is to create a drag, and how easy it is to remember it. Not on things that you're supposed to make yourself.

  • Posts: 1,976

    @Ignatz How do you know no one ever tried it before? There's a first for everything. I suppose that if it isn't done already, that it's already been tried and failed. But it could also mean that no one thought of it yet.

    New things are being made all the time. Because they weren't in use before, did that mean that they had already been used and failed?

    What about apps like Codea? Just because there weren't that many good programming IDEs for iOS, did that mean that they had tried and failed? Then how do you explain the app you're using now?

  • IgnatzIgnatz Mod
    Posts: 5,396

    @SkyTheCoder - google "authentication gestures"

    especially this one

    It has been thought of many times before now, and if it hasn't been done, it's because it is very hard to implement securely. The idea is the easy part - implementation is horrifically difficult.

    Again, before anyone would seriously consider such an approach, they would need to know how many possible combinations there are, and whether there are any frequently used patterns (discovered by exhaustive testing with lots of people) that make an attack easier.

  • edited May 2014 Posts: 1,976

    @Ignatz The number of combinations is infinite because the length of a drag can be any number.

    I don't get what you mean by "frequently used patterns." There is no "pattern," so there is nothing to be frequently used.

    I was unaware that Apple had come up with something similar, but theirs is gesture recognition, mine is dragging in a circle. It's not that hard to implement. It's different enough from Apple's. And besides, I came up with this idea only a little bit after that article was published. It appears Apple is currently trying it and it has not failed yet.

    Go murder someone else's idea, I've had enough. Judge it based on the code, not flaws in the entire concept of passwords. And actually run the code and examine it before you criticize it.

  • IgnatzIgnatz Mod
    Posts: 5,396

    @SkyTheCoder - it's no use my criticising it, because I'm not a security expert. I can assure you though that an expert would find lots of reasons why it wouldn't be practical. Don't take it from me, take it from one of the world's leading experts:

    Bruce Scheier: "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break. It's not even hard. What is hard is creating an algorithm that no one else can break, even after years of analysis. And the only way to prove that is to subject the algorithm to years of analysis by the best cryptographers around".

    All the same, I have tried your code. I don't think including the digits between number touches adds security, because anyone trying to crack it will simply replicate your algorithm, and then just test for different combinations of touches. The final number string also has sequences that can be deconstructed back into a relatively small number of possible touches.

    So basically it seems to be a scheme for entering a string of N numbers 1-8, with some obfuscation created by adding intermediate digits.

    Apple already has a better alternative. You can choose to lock your device with a passphrase instead of a 4 digit number. Each character can be anything on the Apple keyboard, so even a password of only 4 chars has a potential complexity of something like 100,000,000, and if you take XKCD's advice (, you can string a few words in a row, which is much easier than remembering a number - unless you make the number obvious by using birthdates, which kind of defeats the object!

    Please don't take my comments personally. Over the years, I have had the opportunity to do a lot more work on security/encryption than you have, and what I learned most of all was how impossibly hard it was to get it right.

    If you still aren't convinced, read what the experts say, eg

  • Posts: 2,043

    @Ignatz, I like the quote :) This Passdrag example seems to have an infinite number of possibilities, since you can drag it for as long as you want, and change direction whenever and wherever you choose to. But it could probably be cracked as you say, especially since numbers have to go in order.

  • Posts: 791

    @SkyTheCoder: "Again, just a concept. Feedback or opinions are greatly appreciated!"

    Evidently not.

    @Ignatz took the time and provided you with some very constructive critical feedback as requested. Ok, so you might not agree with it, but in my opinion the points he raised are valid and worthy of consideration borne out of many years of experience (which you don't yet have).

    IMHO your "New concept for passwords" is very similar to other concepts already out there. I think it's fantastic that you are thinking in this way, and coming up with these new ideas - just because others have thought of it before you doesn't diminish it - it just means that they have had more time to think through the potential pitfalls. Now you could take this idea forward and develop it more, and you would likely encounter the same issues, or you could do as @Ignatz is suggesting and take this wealth of material that already exists, read it, digest it and push it on further. As Isaac Newton said "If I have seen further it is by standing on the shoulders of giants."

    Another example of people looking at gesture recognition is for securing mobile devices is - although they don't use circles this is a related take on the problem you are proposing to solve.

  • IgnatzIgnatz Mod
    Posts: 5,396

    @West - exactly, the intention is not to criticise @SkyTheCoder for having ideas, but just to warn him that thousands of very smart people have been working on this stuff for many decades, and it is extremely unlikely that amateurs like us will come up with something that hasn't been thoroughly explored.

    It is still fun to play with ideas like this - and I've certainly played with logins and encryption in the past - but security cracking skills are so advanced that any amateur scheme can be destroyed very easily.

    I saw another great quote by Phil Zimmernam, creator of PGP, the famous open source public key encryption software. This guy is a top security expert.

    From Introduction to Cryptography (Page 54):
    *"When I was in college in the early 70s, I devised what I believed was a brilliant encryption scheme. A simple pseudorandom number stream was added to the plaintext stream to create ciphertext. This would seemingly thwart any frequency analysis of the ciphertext, and would be uncrackable even to the most resourceful government intelligence agencies. I felt so smug about my achievement.

    Years later, I discovered this same scheme in several introductory cryptography texts and tutorial papers. How nice. Other cryptographers had thought of the same scheme. Unfortunately, the scheme was presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme.

    From this humbling experience I learned how easy it is to fall into a false sense of security when devising an encryption algorithm. Most people don’t realize how fiendishly difficult it is to devise an encryption algorithm that can withstand a prolonged and determined attack by a resourceful opponent."*

    Anyway, even if we are just rank amateurs, we can still have a lot of fun with this stuff, and I suggest you keep doing that, @SkyTheCoder.

  • Posts: 425

    What about subliminally(?) learning a sequence of notes Since music is easier to remember than numbers(not my idea)

  • IgnatzIgnatz Mod
    Posts: 5,396

    @Coder - they still end up as numbers in a computer - and most people would choose popular tunes, making them easy to crack

  • Posts: 1,976

    @West I am open to feedback and opinions, just not when it's about something I can't control. It appeared that I was being criticized on the authentication and saving, instead of the GUI and the concept.

    @Ignatz This was only supposed to be a step up from PINS, where you can only have 4 characters, it was not supposed to be some super-secure kind of password that you can use for everything important, and that no one could crack.

    If you want to see my progress on encryption, try to decode this:


    No, really. Try to decrypt it, I want to know how hard it is to crack. It's lorem ipsum. And use a program to procedurally decrypt it, not just by hand.

  • edited May 2014 Posts: 425

    @SkyTheCoder i agree that more abstract passwords (pictures,music,movements) are easier to remember and (maybe not) harder to crack. And the encrypted text, does for example a always stands for b or does it change each time or is that part of the challenge :-/

  • Posts: 1,976

    @Coder That's part of the challenge, but I'm testing out a new "progressive seed" option where a character in one spot could be different from a different character in another spot, i.e. 47 could mean "h" in one spot and "i" in another.

  • Posts: 2,043

    @SkyTheCoder, this is encrypted with AlphaCoSi, right?

  • IgnatzIgnatz Mod
    edited May 2014 Posts: 5,396

    @SkyTheCoder - I'm not going to try to decrypt your text, because "Lorem ipsum" is far too small a text to work with, and also, I'm not a cryptananalyst.

    If you are really interested in security and cryptography, I strongly suggest you look at one of the several MOOC courses on it, or that you read a lot (and I mean a lot) about it, including all the math. Then learn how to crack security systems so you know what to avoid in your own.

    The following quotes from experts support this view. I'm including them not to beat you over the head, but because I find all of this very interesting and worth sharing. I've been where you are.

    Schneier: When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.

    ........and from experts on - comments in response to someone's "new" system

    All amateur encryption schemes are insecure. Professional schemes may, or may not, be insecure but the amateur ones always fail. The fact that you are asking this question indicates that you are an amateur.
    To answer your question "After implementing a novel encryption algorithm, how would one go about analyzing its security", well, the easy answer is "no, it's not secure". The reason I can confidently give that answer is that you're a newbee, and newbee ciphers are never secure (unless they are massively overcomplicated; it doesn't sound like that's the case). A newbee is about as likely to create a secure cipher as a blind man would be to paint a good piece of art; neither has any reference as to what works and what doesn't.
    If you want to learn how to be an expert in cryptography, the way to learn is not to design cryptoalgorithms; instead, the way to learn is to break cryptoalgorithms. If you want to get professional review of an algorithm, well, the most reliable way would be to pay for it; however, it's unlikely you'd learn much from it (at least, you won't learn nearly as much as you would if you broke it yourself)
    I recommend taking a read through Applied Cryptography by Bruce Schneier. Cryptography Engineering coauthored by Bruce Schneier is a more modern read and you will probably get more useful information out of it.
    To know whether a given encryption system is secure, cryptographers use the following recipe:

    They publish the system: complete algorithm description and sample implementation with test vectors (the code is not the description; the description should make no assumption on the involved programming language, and yet be sufficient to reimplement it perfectly in any language).
    They lure other cryptographers into gnawing at it and try to break it. The "luring" is about making the algorithm interesting, either through a some kind of mathematical novelty in the structure (e.g. a reduction proof with regards to a well-known hard problem) or impressive performance (see below).
    After enough time and work, if the cryptographers found nothing bad to say about the algorithm, we can begin to say that it may be worthwhile to consider in future protocol designs.

    Let me stress that "enough time" means "at least five years and one hundred cryptographers".
    Is your algorithm secure against Linear Cryptanalysis? Is your algorithm secure against Differential Cryptanalysis? Both of those you can check yourself by running Linear or Differential attacks. Alternatively, publish your algorithm in a public forum devoted to cryptography, for example, sci.crypt on Usenet. Expect it to get torn to shreds by experts. Post the algorithm. Don't post cyphertext only; if you do it will just confirm that you don't understand Kerckhoffs's principle
    "I remember a conversation with Brian Snow, a highly placed senior cryptographer with the NSA. He said he would never trust an encryption algorithm designed by someone who had not earned their bones by first spending a lot of time cracking codes."

    So security is really, really, really, really hard. Have fun, but don't fool yourself you're inventing the next big thing.

Sign In or Register to comment.