Research Ideas

This will serve as my "continously" updated page with random research ideas, for anyone to pick up and start working on. If you have any questions, suggestions or want to get started on something, please let me know.

 

  1. Apps / API / web account user/password bruteforcing

    Source of idea: https://appbugs.co/html/bugs_category.php?c=password_bruteforce

    Several media has covered the story. Online rate-limiting of account logon attempts is obviously highly recommended, but apparently apps & API's seem to be missing out on such security features. I'm curious if the stuff as described in the above link is applicable to other, bigger and more "serious" services like health, politics, religious & financial services. I would like to see more research in this area, including good practices for eventually blocking, slowing down & reporting such attempts conducted "offline" to be reported from app to server once network acccess is available.

  2. Password paste / field

    Certain webpages disallow password paste, and up until Paul Moore and I described keystroke dynamics as a potential threat to privacy and a possible reason for disallowing password paste, nobody got any reasonable answers from companies. In fact we still haven't got any reasonable answers from those who do it. While password managers and developers alike knows their way around this restriction anyway, I'd like to see more work in this area. Why/not allow paste, in a wider context than just simple UX.

    A related idea from Max Spencer & colleagues at Cambridge is Password-Manager friendly (PMF) semantic annotations to improve the effectiveness of password managers. Personally I LOVE the idea, and I would love to see password managers support it, and OWASP create some sort of official "standard" of this.

  3. Online account verification

    Ashley Madison used a username (not email adress) + password to logon, which apparently made it a little harder to do account verification. However account verification have been shown to work using timing attacks, were the remote server responds faster/slower if account actually exists in userDB. While username = email to most people today, the ability to use a "username" or "alias", such as usernames on Twitter, could be a good way to lower the risk of successful account enumeration with a particular service.

    However, for this to work properly, it has to be designed in such a way that at no point can an attacker gain access to additional information that will disclose account names, naming schemes & structures. Easier said than done, and I would really like to hear some thoughts on whether this is actually worth the time designing and implementing, and how it can be attacked.

  4. PINs – length & reuse

    Watch this talk from Howard Smith (Oracle UK) from the very first PasswordsCon in December 2010.

    Data from the Master thesis of Marte Løge, as presented at PasswordsCon & Defcon in Las Vegas, august 2015, shows that people would on average create a shorter lock pattern for their phone, compared to lock patterns for an a) online shop, or b) online bank. Although users were not asked about this behavior, it is tempting to suggest this is simple UX. Unlocking the phone very frequently makes users do a simpler lock pattern. But is this ONLY due to UX, or is there also some risk analysis applied to the physical security of the phone and access to all its contents once unlocked?

    The iPhone pin code analysis & data set originally published by Daniel Amitay, and later on heatmapped and further explained by Joseph Bonneau and DataGenetics originally suggested that users would pick the same PIN for the "Big Brother" app created by Daniel as the one set for their phone.

    I would like to see a (scientific) survey asking people about their reuse of PINs across phone, app unlock (Dropbox and several others has 4-digit PIN unlock options), debit/credit cards, physical access control systems and more. My simple theory is that PIN reuse is even more common than password reuse, when we already know from countless examples such as Sony vs Yahoo (Troy Hunt) that password reuse is high.

    And not to forget: banks & credit card companies offers their customers not only to pick their own 4-digit PIN, but also to get the same PIN on their VISA (debit) and Mastercard (credit) cards, at least here in Norway. The ALE calculations vs expected rise in transaction volume for that would be interesting to see

  5. Mapping global POP/S/IMAP/S presence & configuration

    Update: THANK YOU to John Matherly (@Achillean) @shodanhq for adding another port & reporting options to his service!

    So this is a request very specifically for @ErrataRob, eventually also @shodanhq, but others are more than welcome to look into it as well. I've asked @ivanristic about adding this to Qualys SSLLabs before, but time is always an issue for us all.

    RFC 3501 " INTERNET MESSAGE ACCESS PROTOCOL – VERSION 4rev1" from March 2003 says:

    1. IMAP client and server implementations MUST implement the TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite.  This is important as it assures that any two compliant implementations can be configured to interoperate.  All other cipher suites are OPTIONAL.

    RC4. MD5. What more could possibly your favorite agency want, except plaintext? Worse is, there is afaik no newer RFC that specifically recommends upgrading cipher suite support and getting rid of old & weak cipher suites. Oh, and W*F do ISPs and others continue to support plaintext logins for POP, IMAP and SMTP? If there are any mail clients out there not capable of doint SSL/TLS, they should die ASAP. Unless somebody can explain to me why we need it. And PLEASE, give me a better reason than "need to be RFC compliant".

    So basically what I'd like is:
    A) Some general numbers of ports TCP/25/110/143/465/587/993/995 out there in IPv4 space
    B) Stats on STARTTLS/SSL/TLS availability for ports mentioned
    C) Cert info (Issuer, validity, expire date/time) cipher suites supported

    Why? Well, back to my nagging for SMTP STARTTLS support adoption worldwide, and the https://starttls.info/ service from @einaros, major providers around the world have deployed STARTTLS support for their SMTP servers. Before moving into DNSSEC/DANE/TLSA land, I'd very much like to see the client<->server connections secured as well. You really do not need to spend much time at your local Starbucks or fancy financial district lunch restaurant before you've got credentials enough to spend some time in prison.

  6. Password policy scoring

    Source of idea: Multiple sources, but lets use @Dashlane and use this blog post from them as an example: http://blog.dashlane.com/dating-websites-security/ (Steve Werby also started an amazing project on this which he presented back at PasswordsCon Las Vegas in 2013. Watch it here: https://www.youtube.com/watch?v=EUsjs4X1aT4 <- did you ever finish Steve?)

    Basically they have assigned scores to the password security of 24 dating services online, but no explanation in the blog post itself about the parameters used, and their weighted scores. A good starting point, and I'm sure there are others we can use as well. AFAIK we haven't discussed too deep into exactly WHICH password security features are the most and the least important in various scenarios, although I think we pretty much agree on "Length trumps everything" (Jeff Goldberg, Agilebits, PasswordsCon Las Vegas 2013), no passwords sent by plaintext and PBKDF2 as an absolute minimum for password storage.

    In my case I would like to include several parameters related to the security of the entire account lifecycle; SSL security, 2FA available, STARTTLS support on mailservers, password reset options available, DNSSEC, DANE TLSA (mailservers) and more. The challenge is to not make it too extensive, and eventually be able to automate large parts of it.

  7. TBA