technique posts

Algorithmically derived passwords

in

I’ve been considering a new password storage method for a while now. Currently, I have a system where I compose passwords of pieces of several different values that I have memorized. Each value has a key that I have associated in my head to the value, and I have a file with the keys for each site. Lately, I’ve also been doing part of the password as something derived from the name of the site. This has helped somewhat with making the passwords memorable, but I still frequently have to look at my password file. If someone got a hold of this file, it would take some dedication and knowledge of me, or at least access to the plain texts of some of the passwords, to crack the system. Nevertheless, I’ve been looking for something easier to use and preferably more secure at the same time.

I’ve been looking at options like YubiKeys and 1password, but they have their issues. Today, I came across a cool option wherein passwords are algorithmically derived from a single password and the site name. This is sort of like what I’m doing in my head for some of my newer passwords, but much more advanced, able to produce hash passwords of a desired length and even with character constraints. I read about the idea from a post by Tab Atkins, who has his own solution freely available to use. The comments on his post also led me to SuperGenPass, a similar idea.

Both are of these options built purely using web technologies, making them easy to use anywhere. Both are open source, so I can check their code, verify they are doing what I want, and modify them so they can be slightly different. Neither need to store anything (unless you change the config for SuperGenPass) or require accounts. They have an option to work as a single-page file that can work even offline, wherein you type your master password and the name of the site, and they will give you the password in plain-text to copy elsewhere. SuperGenPass also has a bookmarklet option that can be run from the page you are entering the password on (obviously web only) by using an iframe (requires a third-party server) that can put the password directly into the password field, bypassing the need to copy the password at all.

So these are definitely interesting options to make working with passwords much easier, and the passwords I have for each site can be more complicated and theoretically secure than what I use currently. The biggest danger would be, if someone figures out my master password and what settings I’ve used for the generators, they will have access to any passwords I’ve created. I would probably do multiple master passwords, at least a normal one and an extra-secure one, just to limit the number of accounts they could access. I could even throw in a simple modification to the master password derived from the site name to make it even less of a problem.

Duplicate selectors: Increase specificity without being more specific

in

CSS has a concept of specificity wherein more “specific” selectors take precedence over less specific. Sometimes specificity rules cause a set of property values to be applied while another is desired. This can result in the developer increasing specificity on the desired set to outweigh the other set. When I’ve needed extra specificity, I’ve often use an ‘html’ class on the <html> element or a ‘body’ class on the <body> element. The downsides of are it:

  • is more specific, as in precise, meaning the selector won’t match in a document without those helper classes.
  • has a performance penalty for needing to check a(nother) parent element of the target element.
  • only allows one more unit of specificity at the class level for each parent used.

Today (yesterday), I found a better way that can add any amount of class level specificity (weight) without being more specific (precise), thanks to CSS Wizardry. I’ve been doing this CSS thing for a while, but I hadn’t realized .foo.foo would match <div class="foo">. In essence, you can duplicate a selector and chain it onto itself to create an equivalent selector, but with double the specificity. You can duplicate it as many times as needed to get the desired specificity, e.g. .foo.foo.foo.foo to override .foo.foo.foo, without requiring any parent selectors. Besides the benefits already mentioned, it could be seen as more explicit in its purpose than using parent elements, because there is no other reason to do it. I will have to start using this.

CSS: Inner Border Grid List

in

[note]This post is not about the grid layout spec, but I have created a solution using it to solve the same problem this post is solving.[/note]

Many of the recent designs at Cogneato have had a responsive grid list of items that have a border between them. By grid I’m meaning like an image or product grid where the items flow horizontally and then wrap and are all the same width. By inner border I’m meaning a border around each item except the edges that don’t touch another item. See a more complicated example that uses sub-grids. My solutions thus far haven’t been ideal. But I recently thought of and found some solutions that, when combined, make for a better option.

The biggest difficulty with this type of situation can be getting the items on the same row to be the same height so that all borders meet up. I have been either requiring a fixed height for the items or using JavaScript to equalize the heights on a given row (which of course has to be rerun upon screen resize). The fixed height option means content creators are forced to limit how much content they put in each item or it will be clipped. There is also the potential for extra whitespace when there is less content. Considering the JavaScript option, I definitely try to avoid having the presentation depend on JavaScript. It is a potential performance issue as it has to continuously poll for browser resize and update the height when it changes.

position: absolute

Every time I build this sort of thing, I desire a better solution, but have limited time, and settle on my previous solutions. When doing the most recent site with this sort of grid, I theorized a solution taking advantage of a few other tricks, and later implemented it in my off time. The most important was my relatively recent discovery of how position: absolute with auto works.

Continue reading post "CSS: Inner Border Grid List"

Responsively Changing Date Formats

in

At times in developing a responsive site, the content that is shown needs to change depending on the viewport. One might want to show a hamburger icon instead of a menu on a small viewport or display extra less critical content on a larger viewport. I recently had to show a more verbose format on wide viewports (like “Tuesday June 8, 2014”) and a less verbose date format (like “Tue Jun 8, 2014”) on a narrow viewport to make things fit well. I didn’t like the options I’ve used in the past. I didn’t want to have duplicate content in my raw markup, to need to inject HTML elements into generated date strings, or to involve JavaScript. I tried fixing the width of a wrapper and hiding the rest, but with the non-monospaced font, it didn’t work the same for all cases.

So I did some looking for other options. I found a discussion of a technique that seemed fairly elegant. I had been reluctant to use it in the past because of browser support and just being a bit uncomfortable with it. The technique makes use of the attr() expression to inject content. Since any browsers that support media queries should support attr() and I was using this in a media query, I thought it worth it to embrace it finally. I liked the results and will probably make more use of it in the future, especially since the browsers that don’t support it now have low enough market share to almost ignore.

Continue reading post "Responsively Changing Date Formats"