moonboots

Thanks, edited my post

Thanks for the link. I'll find a place for uxvrt-perls in my hacky copy-paste workflow. I'm currently using tmux paste buffers and shell functions around xclip to move around text.

Thanks, forgot about bash behavior. On Zsh the 'e' doesn't need to be pressed with control.

I use rxvt and never figured out how to paste the clipboard buffer, so I use shift-insert to paste the primary buffer. Unfortunately, the primary buffer can be overwritten without my consent, e.g. an autofocused web input field.

Vim and emacs also have their own shortcuts for accessing the clipboard buffer.

Bash and Zsh provide shortcuts to open a text editor where commands can be pasted and edited before running (Ctrl-x Ctrl-e in bash, need to enable in zsh [2]). I've been using this on Linux not for security but because I'm still confused by X11's primary and clipboard selections [1]. It seems like every time I try to paste a github repo link, I get the last chunk of code I copied and vice versa.

[1] http://www.nongnu.org/autocutsel/

[2] Sample .zshrc to map edit-command-line to Ctrl-x e:

  autoload edit-command-line
  zle -N edit-command-line
  bindkey '^Xe' edit-command-line

edit: fixed shortcut for bash

edit: forgot about my .zshrc

It should be pretty easy to upgrade vulnerable WRT54GL routers. Any volunteers to setup a page that POSTs a newer firmware like OpenWrt or Tomato?

Sandbox iframes allow disabling javascript in a frame, which disables framebusting protection [1] used by sites like vk.com. The better way to framebust is to add the header 'x-frame-options: deny', which isn't broken by html5 sandboxes.

[1] http://en.wikipedia.org/wiki/Framekiller

I prefer text to icons. Text has less ambiguity with the additional benefits of being easier to implement and faster to load (at least for html/css). An example is the new Safari [1] and Chrome devtools, which both stem from the old Safari devtools [2]. The new chrome devtools removes the top row navigation icons, leaving only text like 'Elements' and 'Resources'. It's cleaner and tighter than the old UI without sacrificing usability. Safari 6 removed the text and kept the icons. I find myself constantly lost and cycling through the icons. Admittedly, I only use Safari devtools to debug safari issues.

Back to the original topic, I think auto-save and undo obsolete the save button.

[1] https://developer.apple.com/technologies/safari/developer-to...

[2] this site has chrome screenshots, but it's what safari 5 dev tools looked like: https://developers.google.com/chrome-developer-tools/docs/ov...

I wish pubmed, a primary source for this article, were more usable. I feel troves of interesting studies go unnoticed because it's so difficult to find anything. As an example, I tried searching for 'stretching' in pubmed, and the first result is about mental activity in older adults.

On Linux it's possible to simultaneously map caps lock to both escape and control with xcape [1]. On short presses without any other keys depressed, escape is fired. On press-and-hold with other keys, control is fired. This is great for vim, emacs, and any other application with control shortcuts.

[1] https://github.com/alols/xcape

I chose an io domain my site http://typing.io because of the input/output programming reference. It's also more difficult to find a reasonable .com domain related to typing practice.

The registrar I'm using is about $48/year [1] with no price bumps for renewals.

[1] http://en.gandi.net/domaine/prix/detail/io/

How does this compare to the commercial system Chronon[1]?

[1] http://chrononsystems.com/

Have you considered a newer compression program like xz [1]? The backwards compatibility of Zopfli is only necessary for clients that are relatively hard to update, e.g. browsers. If you are already distributing a custom game client, you could bundle an arbitrary compression library that has a better compression ratio, faster compression time, etc. than gzip.

[1] http://en.wikipedia.org/wiki/Xz

Zopfli can be used with nginx without code changes with the static gzip module [1].

[1] http://wiki.nginx.org/NginxHttpGzipStaticModule

Most existing accounts allow password resets via email, so email compromise would also result in account compromise.

I've been using the following script in my build process to avoid certificate expiration surprises:

  currentDateEpoch=$(date +%s)
  expirationDate=$(openssl x509 -in $my_cert -enddate -noout | sed 's/notAfter=//' | date -f -)
  expirationDateEpoch=$(date -d "$expirationDate" +%s)
  diff=$((expirationDateEpoch - currentDateEpoch))
  
  oneMonthInSeconds=$((30 * 24 * 3600))
  oneWeekInSeconds=$((7 * 24 * 3600))
  
  if [ "$diff" -lt $oneWeekInSeconds ]; then
    printf "Certificate $my_cert needs to be renewed! Expires on $(date -d "$expirationDate" +"%B %_d, %Y")\n" >&2
    exit 3
  fi
  
  if [ "$diff" -lt $oneMonthInSeconds ]; then
    printf "Certificate $my_cert expires in less than a month! Expires on $(date -d "$expirationDate" +"%B %_d, %Y")\n" >&2
  else
    printf "Note: certificate $my_cert expires on $(date -d "$expirationDate" +"%B %_d, %Y")\n" >&2
  fi

Nginx's development branch is generally considered production ready [1]. I trust the nginx core team not to introduce potentially problematic changes. As an example, the recent spdy integration [2] has lived in a parallel branch for over half a year.

The dev branch is officially upgraded to stable infrequently, maybe once a year.

[1] http://blog.bigdinosaur.org/nginx-dev-or-stable/

[2] http://nginx.org/patches/spdy/

I prefer the x230's keyboard [1], which extends the arrows downward into the unused palm rest area. I've used a similar keyboard as the vostro, and I found myself frequently fatfingering home instead of pageup and end instead of pagedown.

[1] http://cdn.gottabemobile.com/wp-content/uploads/2012/05/thin...

The next dev release with websocket proxy support is scheduled for tomorrow [1].

[1] http://trac.nginx.org/nginx/roadmap

Sorry, I misinterpreted your attack, and it's more worrying than I initially thought. I would add some information about the fix, namely adding the header "X-Frame-Options: SAMEORIGIN" [1].

[1] https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Option...

Usually these guarantees mean credits toward future billing. Cloudflare's enterprise plan offers 2500% uptime guarantee, which means if they are down 10% of the time, customers are credited 2.5 months.

It sounds a lot nicer than it is, much like "we never charge for bandwidth".

The kdf should be as slow as possible for an attacker but fast enough for you. If you're using python and the attacker is using C, you can increase security with no usability loss by switching to C and raising the iteration count.

Usually encryption schemes use a key derivation function like PBKDF2 to "stretch" a user's password to generate 128/256 bits for the symmetric cipher. In this case, the attacker cannot bruteforce aes directly because the generated key is "randomly" selected from the impossibly large 256 bit key space. The attacker now must feed his password guesses through the key derivation function, which hopefully will slow the attacker enough that even the smaller space of memorable user passwords is too large to bruteforce.

It doesn't seem so ludicrous if it works.

No key derivation function will protect from very short passwords, which is effectively the scenario here as the author is helping the attacker narrow number of possible passwords to 22472.

As a side note, my interpretation is that the author's password is longer than 6 characters, and he cannot remember 6 of the characters.

SSL doesn't protect against this timing attack. The vulnerability allows an attacker to generate a malicious cookie that the rack server believes is authentic. The attacker sends repeated http/https requests to your server with the malicious cookie and calculated variations in the cookie's authentication code, using slight differences in the server's response time to determine how much of the auth code is correct. It's possible to measure these timing variations, especially if an attacker rents a box in the same data center [1].

The relevant commit [2] and an explanations of equivalent vulnerabilities [3][4]

[1] http://www.youtube.com/watch?v=ehxjAq59xEw

[2] https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d6...

[3] http://rdist.root.org/2009/05/28/timing-attack-in-google-key...

[4] http://codahale.com/a-lesson-in-timing-attacks/

That package is it. It's in the universe repo, which is disabled by default (I think), so I didn't want to claim scrypt was as convenient as openssl.

The scrypt command line utility uses the scrypt kdf to generate a 256 bit key for aes.

Both kdf and cipher are used during single file encryption with openssl and the scrypt command line utility. Openssl implicitly uses a md5 as a kdf during encryption [1.1][1.2]. Cast5 requires a 128bit key, and the kdf helps stretch the user's password to fit this key requirement.

I can understand the confusion, as scrypt is typically referenced in kdf discussions. It's actually somewhat difficult to extract the kdf functionality from the scrypt source code because the code is geared towards single file encryption. See this post for a confused q&a with scrypt's author [2]. Wrappers around scrypt like this python package[3] have made the "mistake" of using the entire encryption pipeline when they just wanted the kdf. Using scrypt in this manner should still be safe, but it will waste some cpu cycles on aes.

[1.1] http://www.openssl.org/docs/apps/enc.html

[1.2] http://www.openssl.org/docs/crypto/EVP_BytesToKey.html

[2] https://news.ycombinator.com/item?id=1350392

[3] http://pypi.python.org/pypi/scrypt/

I recommend the scrypt command line utility [1] instead of openssl. Openssl use md5 as a key derivation function [2], and cost of recovering a reasonable length, randomly generated password is surprisingly low [3]. The costs in the presentation are from 2009, and I can only imagine how they've dropped thanks to a few years of bitcoin-driven gpu/hardware developments. If you trust your code host, e.g. github or bitbucket, this isn't a concern, but neither are plaintext passwords in version control. If you're using a very long, randomly generated password, you're safe as well.

The disadvantage is that you'll need to compile scrypt from source.

[1] http://www.tarsnap.com/scrypt.html

[2] slide 20: http://www.tarsnap.com/scrypt/scrypt-slides.pdf

[3] slide 19: http://www.tarsnap.com/scrypt/scrypt-slides.pdf

Besides the difficulties of patching openssl and nss, what are other technical and political challenges preventing the adoption of djb's crypto primivatives in tls?

> Look at the data passed to the event. The callstack starts at the function attached as a listener to the event.

> Is the event data incorrect? Then the problem is in the code that triggers the event.

> Is the event data correct? Then the problem is in the code listening to the event.

It's difficult to reason about the event triggering code when it's call stack is not available. For a larger code base where an event is trigger in multiple locations with different logic in each location, it may be difficult to pinpoint the triggering code, let alone reason about that code. Direct function calls are much easier to debug because you can walk up the chain of calls and inspect the variables and state of each frame.

The new ssl pinning proposals work very similarly to ssh. When the user visits an https site with pinning enabled, the browser will remember the server's public key similar to ssh's known_hosts.

You're correct that this won't protect against a MITM during this first visit and will cause confusion if an attacker pins his fraudulent public key. However, I would argue that pinning provides a large net security gain in practice. The same model of vulnerable initial visit but secure subsequent visits is used in HSTS to prevent ssl stripping attacks.