On Passwords

This has been bugging me for years but it comes up again and again. So it's time for passwords - a case study:

• Passwords are important, hardly anyone doubts that (well at least for some passwords). Still people don't act accordingly. I know a company that has a policy(wtf!) that the password for any company related account is required to always be the same as the user name. (I mean wtf?!?)
• Passwords are sensitive.
  • Still a lot of servers do auth in plain without encryption. At any stage in between anybody with access to the wire can see them. This is scarier than you might think. For example my dorm has switches that let you read the traffic of hundreds of other people.
  • Even if that is not the case you still have to trust the other end (and that they know what they are doing). I administrate a lot of computers and the people i work with are a rather capable team. I am pretty sure i can vouch for their good will, so i would trust this end. Nevertheless we for example had our ldap passwords stored in plain text and synced them into our university backup system, since we didn't set up the server initially and never thought about.
• Passwords are difficult to get right: This is has many aspects
  
  • they should be memorable. It doesn't help if you have to carry it around in a pocket to know it
  • they shouldn't be too short and lala is too short ;)
    
  • they should be somewhat safe You know the drill, alphanumeric, capitalization, not based on a dictionary word...  Read this and laugh. If you find the full list, you'll be surprised how sexed up thelist is. When setting up our new shell server, we ran all passwords against cracklib as an audit and over half of them fell through!
  • they shouldn't be too safe. It's a sad reality but some setups even if they allow it are plain incapable of processing certain chars/encodings whatever. I had to have my university computer account reset because they had a fuckup in their system rendering passwords with umlauts different when entered and read back. This is germany for christ's sake. How many times a week must they have had this problem?!?
  • they shouldn't all be the same. Most people use the same password over and over, if you get one you potentially have a lot of accounts (i verified this a couple of times).You'd be scared if i had actual figures proving how many people do that.
    There is a difference to be made here: I asked the most tech affine and security conscious people i know and they on average had something like 5 or 6 different personal passwords. The point is they usually have an unobvious scheme of adjusting it and incorporating part of the sites name or similar into it to make them different for each site

A lot of this gone wrong can be learned by bad example from the security "experts" at HBGary and their recent fuckup. So we have all these ideas and that's all nice in theory, but:

1. Why, oh why does every single site have to make up another different insane requirement for passwords. Please use sane somewhat lenient minimum requirements. I propose 7 chars min, one letter, one other and possible an upper case letter.  I can understand requiring numbers or special chars, a minimum length or not all lower/upper case but why the heck would you impose a maximum length of 8 (!) chars or no caps or requiring numbers only. All these make it more predictable, less easy to remember (i still hit sites where none of my standard passwords can be adapted to be accepted) and less safe in the long run. You don't gain security you lessen it!
2. If you insist on restricting your passwords firmly, please, please add your requirements to the login page! I have reset my password countless times on many sites only to remember it when i read the reqs when asked to set the new passwords. That would usually help me more than anything. I have turned to writing the reqs in the security question because it's easier that way.

Synctex

I recently became aware of Synctex the successor of pdfsync.
pdfsync is a technology that allows synchronization between a (la)tex file and the corresponding pdf output. It wasn't the first of its kind but certainly the best i've tried. In practice you need support by both your viewer and editor but then it's down to pressing a command or (shift/ctrl/whatever)+clicking somewhere and you are magically teleported into the other app to the spot corresponding to the one you were at on the other side. Anyone who has texed and needed to proof a doc of more than 5 pages length before will understand that this is invaluable.


For all the goodness, this had some drawbacks unfortunately: pdfsync was based on some tex primitives as opposed to being embedded into the engine, so the output under some circumstances wasn't perfect, it could change the generated rendering and it was incompatible with some popular packages (e.g. colortbl). I have never been bitten by any of these in the last 3 years but it always was a good excuse for viewers not supporting it (they are usually the end that carries the burden).
It unfortunately still has it's place as we will see shortly, so here are links to set up  forward  and backward search underMacOS + vim + skim, evince doesn't have it and never will which leaves you with xpdf and okular on linux, both of which aren't my favourites.

In comes synctex: It is the natural evolution of pdfsync done by the original author and has all the goodies without the down sides. Setting it up under Mac was even easier now that skim supports macvim as a preset :). Just choose MacVim under preferences>sync and put the following in your .vim/ftplugin/tex.vim (assuming you use the vim-latex suite)

let g:Tex_DefaultTargetFormat = 'pdf'
let g:Tex_CompileRule_pdf = 'pdflatex -synctex=1 --interaction=nonstopmode $*'
let g:Tex_ViewRule_pdf = 'Skim'

Look at this for all other MacOS related progs, mupdf, and evince. Okular just needs to be called with

okular --unique 'file.pdf#src:linenumber file.tex'

(That's what i think the evince people should have done instead of using dbus. Oh, well...)

Now for the bad part, lua(la)tex + evince/okular isn't working with synctex. I filed bugs with luatex, evince and okular but i don't expect a solution for this anytime soon. :( That means i am back to pdfsync for now, since i really, really like my luatex. So have fun with that!

Edit: you need to tell vim to call okular/evince with the exact same filename that lualatex produces which is ./file
In order to do that goto compiler.vim which if you installed vim-latex in your .vim is under .vim/ftplugin/latex-suite/compiler.vim otherwise probably somewhere in /usr.
Apply this patch for okular. For evince it really depends which script you use, but read the patch and do it analogously.

Impurity Test endlich online!

Du hörst immer du wärst verdorben, glaubst es aber nicht? Du hast schon vor langem von ihm gehört, aber nie getraut ihn zu machen? Verzweifle nicht, er ist endlich hier! In der Tradition der besten Varianten, die wir kennen, raffiniert durch endloses Durchtesten, perfektioniert durch das verderbte Wesen Vieler. Der Impurity Test ist endlich hier!