Research Ideas

This will serve as a "continously" updated page with random research ideas, for anyone to pick up and start working on.

 

  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. It should be 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 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 there still haven't been any reasonable answers from those who do it. While password managers and developers alike knows their way around this restriction anyway. 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.

  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.

  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.

    There should be 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. The 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

    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 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. 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. There haven't been discussed too deeply 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.

  7. TBA